Reverse engineering is a process of analysing a subject system to identify the system’s components and their interrelationships and to create representations of the system in another form or at a higher level of abstraction.
Why Reverse Engineer?
One of the central issues to be addressed in trying to reduce the cost of software maintenance is that of system documentation. For those old legacy systems that are important to the business functionality, the risks and costs involved in redevelopment from scratch are now significant.
The purpose and objectives of reverse engineering are:
- recover lost information
- facilitate migration between platforms, e.g. OS/DBMS
- improve or provide documentation
- provide alternative views of code, e.g. visualisations
- extract reusable components
- cope with complexity
- detect side effects
- reduce maintenance effort
Levels of Abstraction
Functional abstraction – (also called procedure abstraction) a means of eliciting functions from the target system. In other words, looking at code and working out where it sits in the system.
Data abstraction – a means of eliciting data objects as well as the functions which operate on them.
Process abstraction – the exact order in which operations are performed, e.g. use case analysis.
Reverse Engineering Techniques
Redocumentation
The creation of a semantically equivalent representation within the same relative abstraction level. The goals are to:
- Create an alternative view of the system
- Improve current documentation
- Create documentation based on modifications
Design Recovery
Identifying and recovering higher-level abstractions where the results are used to redevelop the system or develop new, similar applications. Approaches include:
- programming language constructs (identify design decisions)
- problem & application domains
Specification Recovery
Obtaining the original specification of the system to be reversed engineered involves: identifying, abstracting and representing meaningful higher level abstractions.
The specification should be represented in a form that can be easily re-implemented; it should capture the precise semantics of the code.
It can assist comprehension or development of similar systems.
Restructuring
Restructuring is really a form of refactoring. Examples include:
- control flow driven restructuring – involves the imposition of a clear control structure within the code, i.e. a logical layout of control flow.
- efficiency driven restructuring – restructuring a function or algorithm to make it more efficient
- adaptation driven restructuring – changing the coding style for a new language or environment, or conforming with the ‘house style’
Motivating Factors for Reverse Engineering
Product and environment related motivators:
- missing or incomplete design/specification
- out-of-date, incorrect or missing documentation
- increased program complexity
- poorly structure source code
- need to make compatible products
- need to migrate between different software or hardware platforms
Maintenance related motivators:
- static or increasing bug backlog
- decreasing personnel productivity
- need for continuous and excessive change
Commercially related motivators:
- need to extend economic life of a system
- need to make similar but non-identical product (boarding on illegal)
Related posts:
- An Introduction to Program Comprehension
- Program Comprehension Strategies
- Software Evaluation Introduction
- Agent Tasks
- What Not To Do When Maintaining Software Applications
Bookmarking
-
Stumble | Digg | del.icio.us | RSS
