Control flow analysis. The purpose of this analysis is to encode the flow of control of a program for use in the ensuing data flow analysis. In the field of program understanding it is used to make the structure of a program apparent. A number of interesting papers on the subject of control flow and re-engineering are, for instance, [Amm92], [CNR90], and [Oul82].
　　Data flow analysis. Usually data flow analysis is the process of extracting information from a computer program about the possible run-time modification, preservation and usage of certain quantities in it. In re-engineering such techniques are useful to detect dependencies between variables such as def-use chains. A typical example is to locate all the variables that are dependent on date variables to aid in making software year 2000 compliant. More information on data flow analysis can be found in [MR90].
　　Abstract interpretation. A classical application of abstract interpretation is the nonstandard exectution of a program by casting out nines to check arithmetic computations in that program. It is used for program validation and analysis. In re-engineering abstract interpretation can be used for analysis as well, for instance, to do range checks on certain variables to see whether or not they remain in a certain range.
　　Program slicing. Program slicing is a technique to identify the minimal amount of executable code that is needed to give a certain variable its value. Slicing can also be used to calculate the pieces of a program that depend on a given variable, and it can be used to debug a program. In re-engineering it can be used for the same kind of analysis, for instance, to identify parts of code that are responsible for date related calculations. Tip [Tip95] gives an overview of program slicing techniques. A few papers on re-engineering and program slicing are [BE93], [GL91], [GHS92], and [Hal95].

　　We saw above that there are many applications of compiler construction technology in re-engineering. Several phases in which source code is processed by a compiler can be related to the phases that such code will pass during re-engineering. As is well-known (see, e.g., [ASU86] or [WM95]) we can distinguish the following analytic phases in a compiler: the lexical, syntactic, and semantic analyzer where the bulk of the analysis is taken care of. In re-engineering we have exactly the same phases that are also meant for analyzing the source code: the lexical phase for a rough inspection of the code, the syntax analysis for both composing a parse tree and for more involved analysis and the semantic analysis for even more involved analyses as we discussed above.

　　Of course the target of a compiler is to generate code from a source program. In that respect re-engineering and compiler construction differ, however, in [CM96] code generation is used for binary translation of systems from a (legacy) architecture to a modern architecture. Note that code optimization techniques are used in re-engineering as well. To generate optimal code it is necessary that the structure of a program and the dependencies between the variables in the program are made clear. To make a program understandable for human beings its structure and dependencies have to be clear as well. So, it is not surprizing that the compiler optimization techniques such as control flow analysis, data flow analysis and abstract interpretation, are also relevant in re-engineering (see above).

　　We conclude that re-engineering techniques benefit from compiler construction techniques and that the other well-established techniques that are available in the compiler design field could be fruitfully applied in re-engineering as well. We believe that these techniques will attract new interest by their application in re-engineering.