Reverse engineering holds a wide range of tasks that can aid to the understanding and modifying software systems. Its main purpose is to identify and recover program requirements and design requirements information from the system.
The abstraction is the process of ignoring certain details in order to simplify the problem and facilitate the specification, design and implementation of a system to proceed in step-wise fashion. In software maintenance, the following three levels of reverse engineering abstraction are defined: implementation abstraction, design abstraction, specification abstraction.
- Implementation abstraction –
Implementation abstraction is a lowest level of abstraction and at this level the abstraction of the knowledge of the language in which the system is written, the syntax and semantics of language and the hierarchy of system components rather than data structures and algorithms is abstracted.
- Design abstraction –
Design abstraction is the intermediary level of abstraction. This level abstracts how the components are related and control to each other.
- Specification abstraction –
Specification abstraction abstracts the functions by replacing its algorithmic nature with concepts and specific to the application requirements.
Reverse Engineering requires detection of low-level implementations and replacing them with their high-level counterparts. The process eventually as a consequence converts to an incremental formation of an overall architecture of the program.
However, High-level counterpart in reverse engineering does not necessarily mean product with higher level of abstraction. If the level of abstraction of resulting product is at the same level as the original system, the operation is commonly known as “re-documentation”.
If on the other hand, the resulting product is at a higher level of abstraction, the operation is known as “design recovery” or “specific recovery”.
- Redocumentation –
Re-documentation is the recreation of a sound mathematical or logical structure precise to its requirements using a specification language(set of notations defining the behavior of the system) within the same relative abstraction level that is equivalent to the representation of the original system.
This process has 3 purposes/tasks –
- (i). Reinforcing the understanding of the product by creating alternating views of the system using data flows or control flow diagram from source code.
- (ii). Updating the system documentation side by side as changes are being made.
- (iii). Completing the documentation of the newly modified system for future maintenance work on the system.
- Design Recovery –
Design Recovery includes the domain knowledge, external data and deduction to the system to identify and extract meaningful higher-level abstraction beyond those obtained directly by examining the system itself. It leads the system from a low-level of abstraction to higher-level of abstraction.
Design recovery recreates abstraction from a combination of code, existing design documentation (if present), personal experience, and knowledge about problem and application domains.The new design that is the recovered design can be used for redeveloping the system by forming a baseline for future system modifications.
Different approaches which vary in their focus, can be used to recover these designs.
For example, after recovering the design of word search application, it can used in the design of a word search module in a new word editing application.
Attention reader! Don’t stop learning now. Get hold of all the important CS Theory concepts for SDE interviews with the CS Theory Course at a student-friendly price and become industry ready.
- Software Engineering | Reverse Engineering
- Difference between Forward Engineering and Reverse Engineering
- Software Engineering | Requirements Engineering Process
- Software Engineering | Introduction to Software Engineering
- Software Engineering | Re-engineering
- Difference between Software Engineering process and Conventional Engineering Processs
- Penetration Testing and Reverse Engineering
- Levels in Data Flow Diagrams (DFD)
- Levels of Capability Maturity Model (CMM)
- Levels of Software Testing
- Different Levels of Causes in RCA
- Software Engineering | Project size estimation techniques
- Software Engineering | Architectural Design
- Software Engineering | Halstead’s Software Metrics
- Software Engineering | Debugging Approaches
- Software Engineering | COCOMO Model
- Software Engineering | Classification of Software Requirements
- Software Engineering | Classical Waterfall Model
- Software Engineering | Iterative Waterfall Model
- Software Engineering | Spiral Model
If you like GeeksforGeeks and would like to contribute, you can also write an article using contribute.geeksforgeeks.org or mail your article to firstname.lastname@example.org. See your article appearing on the GeeksforGeeks main page and help other Geeks.
Please Improve this article if you find anything incorrect by clicking on the "Improve Article" button below.