A model for assembly program maintenance
- 1 March 1990
- journal article
- Published by Wiley in Journal of Software Maintenance: Research and Practice
- Vol. 2 (1) , 3-32
- https://doi.org/10.1002/smr.4360020103
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 effect 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 re‐examined 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 sub‐routines 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 data‐modified 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.Keywords
This publication has 23 references indexed in Scilit:
- A personal chronicle: creating better information systems, with some guiding principlesIEEE Transactions on Knowledge and Data Engineering, 1989
- Designing documentation to compensate for delocalized plansCommunications of the ACM, 1988
- Program translation via abstraction and reimplementationIEEE Transactions on Software Engineering, 1988
- MicroScope: a knowledge-based programming environmentIEEE Software, 1988
- No Silver Bullet Essence and Accidents of Software EngineeringComputer, 1987
- Software Engineering: Problems and PerspectivesComputer, 1984
- Programmers use slices when debuggingCommunications of the ACM, 1982
- Specifying Software Requirements for Complex Systems: New Techniques and Their ApplicationIEEE Transactions on Software Engineering, 1980
- Programs, life cycles, and laws of software evolutionProceedings of the IEEE, 1980
- The source code control systemIEEE Transactions on Software Engineering, 1975