In the previous articles, I presented the procedure for reconstructing the design of an existing software system and the different steps involved. These steps and procedure are based on the work of E.J.Byrne [1] where he performed the reverse engineering of a Fortran system. He described the procedure as was used to reconstruct and document the design of the program. The recovered design was recorded in a software development environment and used to develop a new implementation of the program. The experiences and observations gained during this work, as described in the previous articles are summarized as follows:
Implementation bias. As we have seen, the most important issue while recovering a design is to separate design information from implementation information. At the implementation level it can be difficult to recognize the information that should not be recorded in the recovered design. On the other hand, its difficult to throw away the information during the abstraction process particularly, when our goal is to reimplement the system. An important thing to be noted here is the design level documentation and the implementation level documentation are different. The design level documentation reveals a high level view of how the program functions, whereas the program documentation reflects the implementation details of the source code. Therefore, the program documentation is implementation biased as it contains the details about the data items, data types, data structures, system interfaces and the code that is influenced by the original implementation language.
Traceability. The recovered design should record links between recovered information and the original sources. This permits traceability between the recovered design and the original implementation.
Domain Information. The domain information is important as the recorded information is sufficient to explain "what" is being done, but not "why." Deeper information is required to understand the significance of a processing step. This information, that is often not recorded in the source code or existing documentation, can be gained with an understanding of the application domain.
Re-engineering. As described in the earlier articles, reverse engineering is done mostly on old systems whose documentation is not up to date. Such systems are, usually, a candidate for re-engineering, i.e. reconstituting the system, keeping in view of its current functionality, in order to enhance its understandability, hence, easing its maintenance. Since it is easy to change the design of a system then its implementation, it is reasonable to change the recovered design. In this way, the recovered design is updated according to the needs and a new detailed design generated, which, can further be implemented using the modern development techniques and programming languages.
