A Survey of Reverse Engineering and Program Comprehension
---
paper_title: Reengineering the Corporation: A Manifesto for Business Revolution.

paper_content:

The article reviews the book “Reengineering the Corporation: A Manifesto for Business Revolution,” by Michael Hammer and James Champy.
---
paper_title: Approaches to program comprehension

paper_content:

Abstract Software maintenance is recognized as the most expensive phase of the software life cycle. The maintenance programmer is frequently presented with code with little or no supporting documentation, so that the understanding required to modify the program comes mainly from the code. This paper discusses some of the current approaches to theories of program comprehension and the tools for assisting the maintenance programmer with this problem.
---
paper_title: The interleaving problem in program understanding

paper_content:

One of the factors that can make a program difficult to understand is that code responsible for accomplishing more than one purpose may be woven together in a single section. We call this interleaving, and it may arise either intentionally-for example, in optimizing a program, a programmer may use some intermediate result for several purposes-or unintentionally, due to patches, quick fixes, or other hasty maintenance practices. To understand this phenomenon, we have looked at a variety of interleaving instances in actual programs and have distilled characteristic features. If the characterization proves to be robust then it will enable the design of tools for detection of interleavings and the extraction of the individual strands of computation.
---
paper_title: The program dependence graph and its use in optimization

paper_content:

In this paper we present an intermediate program representation, called the program dependence graph ( PDG ), that makes explicit both the data and control dependences for each operation in a program. Data dependences have been used to represent only the relevant data flow relationships of a program. Control dependences are introduced to analogously represent only the essential control flow relationships of a program. Control dependences are derived from the usual control flow graph. Many traditional optimizations operate more efficiently on the PDG. Since dependences in the PDG connect computationally related parts of the program, a single walk of these dependences is sufficient to perform many optimizations. The PDG allows transformations such as vectorization, that previously required special treatment of control dependence, to be performed in a manner that is uniform for both control and data dependences. Program transformations that require interaction of the two dependence types can also be easily handled with our representation. As an example, an incremental approach to modifying data dependences resulting from branch deletion or loop unrolling is introduced. The PDG supports incremental optimization, permitting transformations to be triggered by one another and applied only to affected dependences.
---
paper_title: Abstract interpretation: a unified lattice model for static analysis of programs by construction or approximation of fixpoints

paper_content:

A program denotes computations in some universe of objects. Abstract interpretation of programs consists in using that denotation to describe computations in another universe of abstract objects, so that the results of abstract execution give some information on the actual computations. An intuitive example (which we borrow from Sintzoff [72]) is the rule of signs. The text -1515 * 17 may be understood to denote computations on the abstract universe {(+), (-), (±)} where the semantics of arithmetic operators is defined by the rule of signs. The abstract execution -1515 * 17 → -(+) * (+) → (-) * (+) → (-), proves that -1515 * 17 is a negative number. Abstract interpretation is concerned by a particular underlying structure of the usual universe of computations (the sign, in our example). It gives a summary of some facets of the actual executions of a program. In general this summary is simple to obtain but inaccurate (e.g. -1515 + 17 → -(+) + (+) → (-) + (+) → (±)). Despite its fundamentally incomplete results abstract interpretation allows the programmer or the compiler to answer questions which do not need full knowledge of program executions or which tolerate an imprecise answer, (e.g. partial correctness proofs of programs ignoring the termination problems, type checking, program optimizations which are not carried in the absence of certainty about their feasibility, …).
---
paper_title: Recognizing design decisions in programs

paper_content:

The authors present a characterization of design decisions that is based on the analysis of programming constructs. The characterization underlies a framework for documenting and manipulating design information to facilitate maintenance and reuse activities. They identify and describe the following categories of design decisions: composition and decomposition; encapsulation and interleaving; generalization and specialization; representation; data and procedures; and function and relation. The authors discuss how to recognize and represent design decisions. >
---
paper_title: The transition of application programs from COBOL to a fourth generation language

paper_content:

It is becoming increasingly desirable to move older application programs from their traditional mainframe execution environments to networked workstations. These management information systems are most often written in COBOL and store their data in files. A networked environment enables the use of a relational database management system and its fourth-generation access language, SQL. A conceptual framework is described that comprises a variety of strategies for making such a transition. Decision criteria for selecting among them are then presented. Finally, a variety of experiments intended to explore the strategies are recounted. The experiments include efforts to automate parts of the process. >
---
paper_title: SmartFiles: an OO approach to data file interoperability

paper_content:

Data files for scientific and engineering codes typically consist of a series of raw data values whose description is buried in the programs that interact with these files. In this situation, making even minor changes in the file structure or sharing files between programs (interoperability) can only be done after careful examination of the data files and the I/O statements of the programs interacting with this file. In short, scientific data files lack self-description, and other self-describing data techniques are not always appropriate or useful for scientific data files. By applying an object-oriented methodology to data files, we can add the intelligence required to improve data interoperability and provide an elegant mechanism for supporting complex, evolving, or multidisciplinary applications, while still supporting legacy codes. As a result, scientists and engineers should be able to share datasets with far greater ease, simplifying multidisciplinary applications and greatly facilitating remote collaboration between scientists.
---
paper_title: TSME: Maintaining Legacy Systems with Process Driven Software Engineering Technology

paper_content:

This paper presents a case study in applying software engineering technology to the maintenance of legacy systems. We give the design for a software maintenance environment which we are implementing and discuss issues involved in its design and implementation. While the environment is still evolving, it is now used to support one large legacy system and will support several others in the near future. A process-oriented approach was used to design the system used whereby software maintainers teamed with environment builders to develop the environment to enhance the support of existing, mature systems. This approach was used by a DoD software maintenance organization to build an integrated work environment used to promote understandability of code being maintained, provide up-to-date documentation, retain prior system knowledge to minimize the effect of personnel turnover, and enhance productivity for software maintenance. The approach involved combining application users, maintainers, and software engineers together in a working group to build an environment that can support the full maintenance lifecycle using open software technology in a real heterogeneous hardware situation. One criterion was set forth by the group was to build an environment such that whenever possible, commercially-available tools would be used in place of custom-developed ones. Another criterion was to allow for the various tools to communicate with each other and the repository so that information can be shared throughout the entire lifecycle. This is a difficult task as it requires an open interface to be used by the repository and all of the tools in the environment. The automation provided by this environment includes: a task-oriented framework to provide process enactment, a commercial repository, reverse engineering tools, as well as tools supporting each lifecycle activity. The repository forms the basis for the integration of software enginnering and software maintenance data. This papaer points out important components that are indeed useful to a maintainer and shows an approach to address many of the issues involved with building such an environment.
---

Title: A Survey of Reverse Engineering and Program Comprehension

Section 1: Introduction of and Motivation for Reverse Engineering
Description 1: Introduce the concept of reverse engineering in the context of software systems and discuss the motivation behind reverse engineering efforts, particularly for legacy systems.

Section 2: Reverse Engineering Defined
Description 2: Define reverse engineering and related terms within the broader context of the software system lifecycle, explaining different levels and specializations of reverse engineering.

Section 3: Difficulties for the Reverse Engineer
Description 3: Explore the various challenges reverse engineers face, including issues in mapping between different abstraction levels and the decay of system documentation.

Section 4: Approaches to Automating Reverse Engineering
Description 4: Outline different automated approaches and tools that support reverse engineering, such as textual analysis, graphing methods, and execution testing.

Section 5: Synchronized Refinement
Description 5: Describe the hybrid methodology of Synchronized Refinement, which combines automated tools with human guidance for improved program understanding.

Section 6: Application to Legacy Systems
Description 6: Discuss the application of reverse engineering to legacy systems and the increasing importance due to technological advancements and the prevalence of outdated codebases.

Section 7: Conclusions
Description 7: Summarize the key points discussed in the survey, emphasizing the significance of reverse engineering in software maintenance and the demand for efficient tools and methodologies.