X hits on this document





79 / 120

diagrams that illustrate the components of a system as well as their interactions during

execution. The hope is that these diagrams will be literally translated in to program code,

with a perfect correlation between the envisioned system and the implementation. For

small projects, it might be fairly easy to check for consistency between the envisioned

design, and what has been implemented, but this is not likely so for large projects. When

reverse engineering is continuously used during software development, the information

gained could be used to update the design diagrams at all levels of granularity [2]. The

challenge here is for the computer programmer to interpret the information gathered from

these reverse engineering tools. This will require the programmer to draw upon a skill-

set that ranges from low-level system concepts to high-level design. Unfortunately, the

future offers little help in undoing the mistakes of the past.

The problem of identifying concrete, reusable components within a software

system is especially difficult because as [7] states, “engineers do not know how to design

and build truly modular systems from scratch, let alone when starting from legacy code.”

In [7], Weide and Hollingsworth's main thesis is that while reverse engineering of legacy

software is inherently intractable, some of us will inevitably find ourselves in a situation

where no other option is available because the cost of rewriting a large, complex software

system is prohibitive. In addition, should one choose to absorb the cost of rewriting a

system from scratch, there are no known software development techniques that can

guarantee a newly-designed system that will not need to be reengineered at some point

down the road.


Document info
Document views445
Page views446
Page last viewedTue Jan 17 03:13:06 UTC 2017