Suite101

Design Recovery


© Faisal Bin Bashir

Design Recovery Defined

Design recovery is a subset of reverse engineering in which domain knowledge, external information, and deduction with fuzzy reasoning are added to the observations of the subject system to identify meaningful higher level abstractions beyond those obtained directly by examining the system itself.

Design Recovery - A Brief Discussion

Software maintenance and harvesting reusable components from the software, both require that an analyst reconstruct the software's design. Unfortunately, source code does not contain much of the original design information, which must be reconstructed from only the barest clues. Thus, additional information sources, both human and automated, are required. Further, because the scale of the software is often large (hundreds of lines of code or more), the analyst also needs some automated support for the understanding process.

Design recovery recreates design abstraction from a combination of code, existing design documentation (if available), personal experience and general knowledge about problem and application domains. The term abstraction is used in its general sense.

The recovered design abstractions must include conventional software engineering representations such as formal specifications, module breakdowns, data abstractions, data flows, and program description language. In addition, they must include informal linguistic knowledge about problem domains, application idioms, and the world in general. In short, design recovery must reproduce all of the information required for a person to fully understand what a program does, how it does it, why it does it, and so forth. Thus, design recovery deals with a far wider range of information than found in conventional software engineering representations or code.

Design recovery occurs from a spectrum of activities from software development to maintenance. The developer of new software spends a great deal of time trying to understand the structure of similar systems and system's components. The software maintainer spends much of his/her time studying a system's structure to understand the nature and effect of a requested change. In each case, the analyst is involved in design recovery. Thus, design recovery is a common, sometimes hidden part of many activities scattered throughout the software life cycle.

Go To Page: 1


The copyright of the article Design Recovery in Software Re-engineering is owned by . Permission to republish Design Recovery in print or online must be granted by the author in writing.

Post this Article to facebook Add this Article to del.icio.us! Digg this Article furl this Article Add this Article to Reddit Add this Article to Technorati Add this Article to Newsvine Add this Article to Windows Live Add this Article to Yahoo Add this Article to StumbleUpon Add this Article to BlinkLists Add this Article to Spurl Add this Article to Google Add this Article to Ask Add this Article to Squidoo


Here's the follow-up discussion on this article: View all related messages




For a complete listing of article comments, questions, and other discussions related to Faisal Bin Bashir's Software Re-engineering topic, please visit the Discussions page.