A model for assembly program maintenance

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.

Business rule extraction techniques for COBOL programs

“…To expedite the software maintenance process, the business rule extraction process should be automated as much as possible. However, our previous work on software reverse engineering (Heisler, Tsai and Powell, 1989;Chen et al, 1990;Chen, Tsai and Chen, 1992;Heisler, Kasho and Tsai, 1993;Ong and Tsai, 1993;Chen et al, 1994;Joiner et al, 1994, Huang, Tsai andSubramanian, 1996;Joiner and Tsai, 1997) has shown that it is extremely difficult, if not impossible, to devise an automatic program understanding tool. This is also true for business rule extraction.…”

Software maintenance—an industrial experience

“…To understand software, a functionality model is needed. This functionality model must be tightly coupled with the code (S. Chen et al, 1990Chen et al, , 1992Heisler, 1993;Huang et al, 1995) as the user's main aim is to understand the code. There should be traceability between the functionality model and the code.…”

Program view generation and change analysis using attributed dependency graphs

“…Most proposed systems to support software understanding are built around the concept of a program information base (Ambras and O'Day, 1988;Calliss et al, 1988;Chen, Y.F. et al, 1990;Chen, S . et al, 1990;Collofello and Orn, 1988;Heisler et al, 1993;Linton, 1984;Rajlich et al, 1988;Yau and Tsai, 1987).…”