Paper Review: Reverse Engineering and Design Recovery A Taxonomy

From time to time you come across a paper that fully describes a subject, so much so that all other writing on the area either references it or rip it off. Reverse Engineering and Design Recovery A Taxonomy is one such paper; and I will now dip into it:

Chikofsky and Cross outline six key terms used within the domain of reverse engineering:

Forward Engineering:

This is the “traditional” process of moving through the stages of design, starting at the highest level of abstraction moving to a specific implementation.

Reverse Engineering:

This involves analysing a “subject” system in order to determine its components and the relationship between those components. It also involves the creation of alternative representations of the system, usually at a higher level of abstraction. Reverse engineering does not involve changing or replicating the system, it is only concerned with an examination of the system and can occur at any stage in the software development life cycle.


Whereas reverse engineering will often lead to the abstraction level being raised, re-documentation is concerned with creating an alternative view at the same abstraction level. This alternative view is usually targeted at a human audience, and attempts to recover documentation for a system that for whatever reason no longer exists. A number of tools exist to make the task of re-documentation easier, e.g. pretty painters and diagram generators.

Design Recovery:

This is the process of adding “domain knowledge, external information and deduction” to information directly garnered from the subject system. It is not a process on its own, but is incorporated in reverse engineering. In some instances, it provides a wider range of information then the system itself can provide.


Restructuring like re-documentation occurs at the same abstraction level; however it is concerned with modifying the representation, whilst providing the same overall outcome. It often involves (but is not restricted to) the restructuring of code and models. Changes are made to components so that they produce the same result, but improve the way they achieve it.


Also referred to as renovation or reclamation, re-engineering is the process of amending the subject system. As a process it will provide functionality the system should have originally had, or make changes to meet new business needs. The process usually involves a reverse engineering aspect to understand the subject system, followed by a forward engineering aspect to implement the changes.

The paper goes on to then outline six objectives for the future development of reverse engineering:

Cope with complexity:

Better methods and ways of automation in order to deal with large complex systems.

Generate alternative views:

Usually alternative views are graphical, these are expensive to maintain, both in time and money. Reverse engineering can facilitate the the auto-generation of graphical and non graphical views.

Recover lost information:

Design recovery in particular allows us to discover information about the system that is missing from the documentation.

Detect side effects:

Provides a method to deliver observations on the results of poor design or subsequent maintenance.

Synthesize higher abstractions:

As a discipline reverse engineering requires improved processes, (most likely automated) for the production of alternative views that “transcend to higher abstraction levels”

Facilitate reuse:

Re engineering can assist in the identification of reusable components from the subject system.

As a final point the paper discusses the economics of Reverse Engineering; drawing attention to, understanding and maintenance is particularly costly for software owners. Over the complete life cycle of a product, maintenance may account for “50 to 90 percent”, thus the potential for savings using reverse engineering techniques could be significant.

For me it’s interesting to see that the principals outlined here, 20 years on are still as valid today. As software engineers we often believe we’re breaking boundaries, but most of the time this is not the case. Surprisingly though, in these 20 years we have actually achieved very little in expediting these processes. Having worked on two design recovery projects in the past, one in the public sector and one for a large UK bank, industry seems content with approaching the majority of the work manually.

Paper Review: Reverse Engineering and Design Recovery A Taxonomy