What is Reverse Engineering?

Reverse Engineering – from product to design drawing, from source code to requirement

The term Reverse Engineering has its origins in mechanical engineering and hardware analysis, where the decoding of designs from finished products is widely used for the purpose of analysing competitors or improving one’s own products. Nowadays, Reverse Engineering is also used in software development, although licence conditions often prohibit such a procedure by external parties¹.

A general definition of Reverse Engineering – sometimes abbreviated as RE – is provided by Elliot J. Chikofsky² and James H. Cross II³ in „Reverse Engineering and Design Recovery: A Taxonomy“⁴:

„Reverse engineering ist the process of analyzing a subject system to identify the system’s components and their interrelationships and create representations oft he system in another form or at a higher level of abstraction“.

Reverse Engineering and related terms

There are always discussions about Reverse Engineering and related terms. For this reason, Elliot J. Chikofsky and James H. Cross II not only provide a definition of Reverse Engineering, but also explain the terms Redocumentation, Design Recovery, Forward Engineering, Restructuring and Reengineering. The aim is not to create new terms but to rationalise terms already in use.

• Reverse Engineering is the process of gaining sufficient understanding of a product at the design level to support its maintenance, improvement or replacement. In software development, it is a part of the software maintenance process that helps to understand the system sufficiently to make decisions about it. In this process, the system is not changed in any way.
• Redocumentation is a sub-set of Reverse Engineering that involves recovering lost or non-existent documentation about the system.
• Design Recovery is a second sub-set of Reverse Engineering where the goal is to reproduce all the information a person needs to fully understand what a programme does, how and why it does it.
• Forward Engineering refers to the process that leads from requirements through design to implementation of a product. So while the existing system is the starting point for Reverse Engineering, it is the end point for Forward Engineering.
• Restructuring – or Refactoring, as it is now usually called – is the process of changing the underlying structure of a system without affecting its external behaviour.
• Reengineering refers to the redesign and implementation of a system in a new form. A distinction is made between two forms: in “pure” Reengineering, the system is merely reconstructed without adding functionality; in “extending” reengineering, the system is reconstructed in order to change existing functionality or add new functionality.

In addition, the term Architecture Reconstruction is also used from time to time. An Architecture reconstruction is a Reverse Engineering with the aim of creating a description of the architecture of a system.

Goals of Reverse Engineering

There are a number of goals addressed in Reverse Engineering (and appropriately named by Elliot J. Chikofsky and James H. Cross II):

• the management of complexity,
• the generation of alternative views,
• the recovery of lost information,
• the recognition of side effects,
• the synthesis of higher abstractions, and
• the facilitation of reuse.

Interestingly, many of these goals coincide with the approaches of Clean Code software development. Clean Code calls for the clear, understandable, comprehensible, logical and disciplined implementation of code. The goal is to produce software efficiently and effectively, while designing the code to be easily readable, changeable, extensible and maintainable. In other words, Reverse Engineering and Clean Code are great complements to each other.

Reverse Engineering in software development

Today, many organisations not only face the problem of replacing their information systems with new ones, but at the same time they need to maintain control over their legacy applications or code. Reverse Engineering offers the possibility to

• recover lost information,
• understand existing software architectures with their components and corresponding interrelationships and functionalities,
• restructure complex systems,
• transforming old systems into new and more maintainable architectures or
• porting software.

And thus, together with Forward Engineering, Reverse Engineering becomes Reengineering.

Impulse to discuss:

Can the emergence of Legacy Code be avoided with continuous Reverse Engineering?

Notes:

[1] “You are not permitted to reverse engineer the source code or data structures of the software manually or by machine.” – This or similar wording can be found in the licence conditions of software manufacturers that explicitly prohibit Reverse Engineering. Whether such regulations apply in all countries and under all circumstances, however, should be checked on a case-by-case basis.
In the European Union, Directive 2009/24/EC of the European Parliament and of the Council of 23 April 2009 on the legal protection of computer programs explicitly prohibits the decompilation of software unless it is done to adapt interfaces.
[2] Information about Elliot J. Chikofsky
[3] Information about James Henry Cross II
[4] Reverse Engineering and Design Recovery: A Taxonomy, see also IEEE Software, Vol. 7, No. 1, DOI 101109/52.43044

Here you will find additional information from our Smartpedia section:

What is Legacy Code?

How does Pair Programming work?