Reverse engineering restricts itself to investigating a system. Adaptation of a system is beyond reverse engineering but within the scope of system renovation. Redocumentation focuses on making a semantically equivalent description at the same level of abstraction. It is in fact a simple form of reverse engineering. Tools for redocumentation include, among others, pretty printers, diagram generators, and cross-reference listing generators. In design recovery domain knowledge and external information is used to make an equivalent description of a system at a higher level of abstraction. So, more information than the source code of the system is used. The notion restructuring amounts to transforming a system from one representation to another one at the same level of abstraction. An essential aspect of restructuring is that the semantic behaviour of the original system and the new one should remain the same; no modifications of the functionality is involved. The purpose of re-engineering or renovation is to study the system, by making a specification at a higher abstraction level, adding new functionality to this specification and develop a completely new system on the basis of the original one by using forward engineering techniques.

　　3 Specific Languages and Re-engineering

　　In this section we will give the reader an impression on the relation between specific programming languages and re-engineering.

　　Since many business-critial systems that need re-engineering are written in COBOL there are quite a number of papers available that discuss methods and techniques that focus on COBOL. For instance, in [GBW95] the re-engineering of 50,000 lines of COBOL to Ada is described. The goal was to do it as automatically as possible using compiler construction techniques. An example of the use of program slicing to aid in re-engineering COBOL can be found in [NEK93] and [CFV93]. In [NM93] Software Refinery, a tool originally developed primarily to generate programming environments, is used to build a modularization tool for COBOL. In [Zuy93] aspects of re-engineering and their relation to language technology are discussed. We mention the compilation of COBOL code to equational specifications, their restructuring and simplification, and regeneration of COBOL code from them. Moreover COBOL is compiled to an intermediate language supporting both all the features of COBOL as well as those of JCL. Various tools support these compilations. In [BFK 94] and [BFKO93] denotational semantics is advocated as a formal foundation for understanding COBOL programs. These ideas are implemented in a tool for the reverse engineering of COBOL-74 programs.

　　Not only COBOL is subject to reverse engineering. We mention [OC93] in which a tool combining static and dynamic information for analyzing C programs is described. In [CCC93] a method is described to produce design level documents by static analysis of Ada programs using data flow analysis. Finally, in [Byr91] we can find a method to convert Fortran programs into Ada code. This is done via analysis of the Fortran code followed by a reimplemention of the extracted design in Ada. Needless to say that in the above cases generic language technology and compiler construction techniques play an important role.

　　4 Compiler Construction Techniques and Re-engineering

　　Many re-engineering tools use compiler construction techniques. When constructing a compiler these techniques are used to go from a high-level language to a low-level implementation. When re-engineering a legacy system those techniques are used to move from a low-level implementation to a more abstract level. In compiler construction terms we could say that re-engineering amounts to the decompilation of source code into its specification.

　　A number of standard techniques in compiler construction are listed below together with their applications in the field of re-engineering.
Scanning. Usually a scanner performs the lexical analysis of a program, it tokenizes programs to be fed to the parser. In re-engineering, the technique of lexical analysis serves the purpose of program understanding. It can be used to locate, for instance, a specific identifier in the source code and it can thus be considered as an intelligent grep(1) facility. Many so-called Y2K-tools like SEEC COBOL Analist [SEE96] use scanning techniques to find date related identifiers and variables, e.g., YEAR, YY, MONTH, CENTURY, etc., in the code of legacy systems.
The usefulness of scanner generators for re-engineering is quite obvious. For the COBOL language numerous dialects exists among which even non official ones and the development of scanners for each of these dialects is too expensive. Since the scanners are only slightly different, a generic approach using a scanner generator is appropriate.

　　Parsing. Usually a parser is used to determine whether or not a string of tokens could be generated by a grammar. Re-engineering tools work on the (abstract) syntax trees yielded by the parser. They can be used to calculate, for instance, the McGabe and McClure cyclometric complexity measures. Such metrics characterize the complexity of programs and give an indication of the costs to re-engineer them.
At the syntactical level, there are many variations in the various COBOL dialects, and it is time-consuming to develop specific parsers for them from scratch. The use of parser generators ensures the correctness of parsers and gives a considerable reduction in implementation effort.

　　Type checking. One of the standard static checks of a compiler is type checking. In the realm of re-engineering type checking results can be stored in the (abstract) syntax tree to be used for inspection later on. It can also be used to locate variables of the same type, for instance, variables of the type PIC 99 in COBOL programs, in order to locate possible date related variables that may give rise to year 2000 problems.
Type checkers can be defined using syntax directed translation mechanisms, such as attribute grammars [AM91] or algebraic formalisms [DHK96]. The benefits of these formalisms are the strong relationship between syntax and semantics, and the ease of constructing such specifications. Formalisms that support some form of modularity provide facilities for re-usability in case of dialects.

更多軟考資料請?jiān)L問：考試吧軟件水平考試欄目

希望與更多網(wǎng)友交流，請進(jìn)入考試吧軟件水平考試論壇