Using Prolog for Reverse-Engineering and Validation

Using Prolog for Reverse-Engineering and Validation K. Lano∗

P. Breuer†

Reverse-Engineering and Validating COBOL

abstract ........................... ........ . . . . . ........ . ...... . ..... . . . . .... . . .. .... ..... ... .. ..

A suite of tools for reverse-engineering and validating COBOL programs has been developed as part of the ESPRIT REDO project [5]. These tools produce functional abstractions and object-oriented designs and documentation from raw source code, with the aim of improving comprehensibility and maintainability.

UNIFORM

... ... parse ...... . K......... ......... ...........

On loading, the application source code is parsed and immediately transformed behind the scenes into an intermediate language UNIFORM [8], which is somwhat simpler than COBOL, in order to facilitate further operations, and all the tools work from this representation of the application. The representation is maintained in a persistent database [3], and is also available to the user for certain operations. The semantics of UNIFORM has been completely formally specified [?], so the transformation apparently succeeds in giving an unambiguous formal semantics to COBOL (!) but it should be borne in mind that formal specifications need not be fully deterministic, and in fact many different implementations will satisfy the specification used. The tools work only on the logic of the common abstraction.

Z++ ... . .. re. . .... engineer ..... . . . . . . . ..............

COBOL Figure 1: The re-engineering cycle.

The functionality of these methods is then abstracted into a simple first-order functional language [2], via an interactive process with an automatic normalisation feature. Initially, an entirely automatic ‘abstraction’ is performed, resulting in a very readable specification because the normalization succeeds in re-identifying many differing implementations of the same concept [1]. Many user-controlled transformations and operations on the initial abstraction are available through menus, and these facilitate the engineering of an improved (structured) and functionally correct specification of the application. Standard refinement operations alOutline object data-designs are then sug- low re-engineering of the application code from gested to the user through built-in heuristics teh specifications. The functional abstractions which identify significant subsections of the code themselves are incorporated into the object deusing the data-flow graph derived from the UNI- scriptions as specifications of the methods, and FORM code as a guide, The outline objects the whole ensemble of objects with formal abgroup together data which appears to be depen- stractions instead of application code constident or inter-dependent and list sectios of code tutes the high-level Z++ specification of the apwhich update or access it as potential methods. plication [6]. Further documentation can be At this stage, the object classes usually have produced from this level, if required. only one object instance each, and abstraction at a later stage establishes proper hierarchies. The components of the system are: • Verification condition generator.

∗ Oxford University Computing Laboratory, Programming Research Group, 8-11 Keble Road Oxford OX1 3QD.

• Parser and translator for COBOL. 1

• Abstraction generator and normaliser.

Oxford University Computing Laboratory, 1991.

• Design recogniser.

[2] Breuer P., Lano K., From Code to Specifications: Reverse Engineering Techniques, Software Maintenance – Research and Practice, 1991, to appear.

• Regenerator of code from abstractions. Related tools, which parse Z and Z++ [6] specifications, and generate psuedocode and emulators for these specifications, have also been constructed.

[3] Cartmell J., Alderson A., The Eclipse TwoTier Database, Chapter 5, ECLIPSE manual, IPSYS Software Ltd, Marlborough Court, Pickford St., Macclesfield, Cheshire, 1990.

Techniques

[4] Gries D., The Science of Programming, Springer-Verlag, 1981.

All the tools have been written in Quintus Prolog and Quintus ProWindows [9]. Prolog was chosen in order to express the many rewrite transforms of the toolset conveniently and succinctly. Some knowledge-based techniques were also employed, in implementing Gries’ heuristics [4] for generating candidate loop invariants, as part of the verification process, and in the heuristics which guess at program purpose during the reverse-engineering process. The tools themselves have an object-oriented design, and this is directly expressed in the user interface: the current software fragment being operated on by the tool is viewed as an object instance, with attributes: text, data-flow graph, and functional abstraction, presented in one window, while operations: Abstract, Generate design, and so forth, are presented as buttons in another window. The processes of building object-class descriptions from code involve extensive user interaction, in order to incorporate the maintainers knowledge into the production of a good design, but the processes of abstraction and language translation are automatic. The database used by the tools is modelled on the Eclipse objectedoriented database [3], and work is continuing to build an interface between the tools and the Eclipse database. The tools consist of over 10,000 lines of Prolog code, and they have been used in practical reverse-engineering and validation of large dataprocessing applications [2]. The code-generation tools have been applied to large systems, such as a radar track-former [7], whose specification consisted of 20 pages of Z schemas.

[5] Katsoulakos P., Reverse Engineering, Documentation and Validation: The REDO Project, ESPRIT 89 Conference, Brussels, 1989. [6] Lano K., Z++ , An Object-Oriented Extension to Z, Proceedings of the 5th Annual Z User Meeting, December 1990, SpringerVerlag, Workshops in Computer Science Series, 1991, to appear. [7] Lano K., The Transformation of Specifications into Code, REDO Project Document TN-2487-PRG-1023, Oxford University Programming Research Group, 1990. [8] Stanley-Smith C., Cahill A., UNIFORM: A Language Geared To System Description and Transformation, University of Limerick, 1990. [9] Quintus Prolog Version 2.5 Manual, Artificial Intelligence International Ltd., Watford, U.K.

References [1] Breuer P., Understanding Programs through Formal Methods, TR-14/91, 2