Generic Programming Language Technology

　　5 Generic Programming Language Technology and Re-engineering

　　To what extent depend various re-engineering tools on specific programming languages? Many tools are geared towards COBOL (or some of its dialects), but some re-engineering tools claim to be language independent.

　　We will classify language (in)dependence in the following categories:

　　We call a system language-independent if it has no built-in knowledge of a specific language. An example is the UNIX tool grep(1), that can be used for simple textual searches in source files.
We call a system language-dependent if the knowledge of a language is hard-wired in the system, e.g., a C-compiler. This knowledge can be implemented in the system by hand, via a generator, or via a combination of these approaches.
We call a system language parameterized (or generic) if the language is a parameter of the system and upon instantiation with a language definition a language-specific system is obtained. Examples are the Synthesizer Generator [RT89] and the ASF+SDF Meta-Environment [Kli93, DHK96].
Generic language technology developed during the eigthies and embodied in programming environment generators such as, for instance, the Synthesizer Generator [RT89], Software Refinery [Rea92], the PSG system [BS86], CENTAUR [BCD 89] and the ASF+SDF Meta-Environment [Kli93], forms now the basis for interactive re-engineering systems. Such systems provide facilities for program analysis, visualization, code restructuring, and automatic language conversions.

　　Since many legacy systems are polylingual it is important that re-engineering systems are based on generic language technology. We are confronted with programs or even complete systems written in numerous dialects of old fashioned programming languages which have to be understood and analyzed. Developing new tools for all the dialects is far too expensive and can be done more effectively using generic techniques. So, there is a strong connection between re-engineering and the fields of programming environment generators and compiler generators. The generic aspect is thus extremely valuable in re-engineering, see [PP94a].

　　The def-use relations in programs, for example, are in fact language independent, however their implementation is often language dependent. In [Moo96] a generic data flow language is defined which is powerful enough to do all kinds of data flow analysis. An arbitrary language is translated to this data flow language.

　　Various new, generic, approaches to program analysis exist. In [BDFH96] an equational logic language, PIM [Fie92], is presented which can serve as a intermediate language representation to solve problems in the field of program slicing, symbolic evaluation, and dependence analysis. It is designed to be used by compilers and analysis tools to process imperative langauges and can be used for re-engineering purposes as well. Other approaches include static shape analysis, security analysis, and the generation of static analysis algorithms from semantic definitions. An overview of recent work in these areas can be found in [HN96].

　　6 Research Directions

　　One of the challenges is how to formally define the syntax and the semantics of the old fashioned programming languages one encounters during re-engineering. For example, in [Man96] the syntax of COBOL-85 is formally defined in SDF [HHKR92] using the ANSI definition of COBOL-85 [ANS85]. Are the various language definition formalisms powerful enough to be used for this purpose?

　　Below we will list a number of research questions generated by applying compiler construction techniques in re-engineering.

　　Higher-level techniques for lexical analysis, that permit easy extraction of information, such as call graphs, from programs written in languages for which no parser is available.
Application of GLR parsers [Tom85, Rek92] to generate parsers for families of COBOL or PL/I language dialects. Note that conventional LALR-techniques break down (i.e., generate many shift-reduce conflicts) when various dialects have to be covered by a single parser.
Generic data flow analysis.
Visualization techniques for presenting the results of program analysis.
Knowledge representation techniques for encoding certain implicit aspects of programs such as dependencies on their operating context, programming conventions and techniques, and application specific information.
Query techniques to retrieve all kinds of syntactic and semantic information about a program, see [PP94b, BKV96a].
(Automatic) program transformation techniques for dialect conversion, systematic editing and correction, and conversion to object-oriented languages.
Concluding we could say that challenging research in (generic) programming language technology is inspired by problems encountered in the field of re-engineering

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

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