 |
 |
||
 |
 |
|
 |
|
 |
|
 |
|
 |
|
 |
|
 |
|
 |
|
 |
- precursor for maintenance and re-engineering applications
- front-end for conceptual modeling and design recovery tools
- input to project decision making processes
- program understanding tool
Reverse engineering a subject system involves two distinct phases:
- the identification of current components and their dependencies
- the extraction of design information and system abstractions
The first phase of the process, the extraction of software artifacts, is language-dependent and essentially involves parsing the subject system and storing the resultant artifacts. We use a database specifically designed to represent graph structures. The parsing system currently supports the programming languages C, C++, COBOL, and Java.
Our approach to the second phase features language-independent composition algorithms which generate hierarchies of subsystems. Hierarchical structures are formed by imposing equivalence relations on the resource-flow graphs of the source code. These relations embody software engineering principles that concern module interactions, such as low coupling and high cohesion. We also formulated software quality criteria and metrics to evaluate subsystem structures. The quality measures quantify the encapsulation effect of individual modules or subsystems, as well as the effectiveness of module or subsystem compositions with respect to separating concerns. Using these subsystem composition facilities, which are supported by the graph editor, software structures such as call graphs, module graphs (including file dependency graphs) and directory hierarchies, can all be summarized, analyzed, evaluated, and optimized subject to software engineering principles. Being able to retrieve, browse and trace these structures effectively is a key to system comprehension.
Conveying and communicating the wealth of information generated as a result of reverse engineering a subject system is a difficult challenge, made even more difficult by the inclusion of both visual and spatial data. Both types of representation, however, are necessary. Visual models make use of the human visual system's ability to recognize and appreciate patterns and motifs, while spatial representations allow for interactive inquiries and systematic exploration of structures. Experience has taught us that effective interaction and presentation of both kinds of information are the key to building accurate mental models of underlying software.
We are currently investigating techniques for improving the Rigi system by applying our methodology to diverse program understanding scenarios and selected target domains. Two key requirements - flexibility and scaleability - have been addressed by making the system user-programmable. A scripting language (RCL) has been incorporated into the editor (rigiedit), allowing users to automate and codify any aspect of the above phases, and they can also access a large library of scripts that have been refined by experts in reverse engineering. In addition, the user-interface is now fully customizable. This enhanced user control allows you to tailor the environment to your own needs, providing a smooth transition between manual, semi-automatic, and automatic reverse engineering, as well as achieving the goals of domain-retargetability.
This approach has been successfully applied in several different domains, including project management, documenting software systems with views, using spatial and visual information provided by the editor in reverse engineering, personalized hypertext, and re-documenting legacy software systems.
What
it is
How it works
Features
Platforms
Methodology
Success
Glossary
FAQ