  |
|
|
|
A key objective of design recovery is to develop structures that would help the software engineer understand a program or system. Understanding is critical to many activities maintenance, enhancement, reuse, the design of a similar system, and training, to name a few.
1. Supporting program understanding for maintenance 2. Supporting population of reuse and recovery libraries 3. Applying the results of design recovery In this article we will discuss the first step only. Because it is the primary and the most important of all, so I'll discuss it in more detail. Step one: Supporting program understanding for maintenance In this step we emphasize on how a program analyst or a software engineer looks at a program during the process of maintenance, and then try to use this knowledge in designing an automated tool for this purpose. The analyst first looks for the large organizational structures such as subsystem structure, module structure and important data structures. Next, he or she recovers various useful design structures and expresses them in abstracted forms, such as informal diagrams, informal concepts and relations, design rationale, module structures, flow and control. In the course of this, the software engineer keep track of the relationship, or to be more precise, the mapping, between the various abstractions and the segment of code that implement them. Now, let us look at the kind of questions a software engineer asks when trying to understand a system. What are the modules? Some programming languages formalize the notion of a module and provide constructs to define it, so the modules and subsystem structures are easy to determine directly from the source code. For those languages that do not provide constructs, the software engineer must use a combination of human intuition and experience, clues from the source code structures, and some knowledge (expectations) of the conventional organization patterns for applications of the type under consideration. Expectations derived from organizational conventions are powerful and efficient mechanisms for helping the software engineer understand a system. For example, based on their knowledge of organizational patterns, experts in the domain of Unix-like multitasking would expect to find a module that does process management and contains routines for the creation, suspension and deletion of processes. In addition to identifying large-scale structures like modules, we also need to associate with informal semantic concepts. That is, we need to provide semantically rich natural language abstractions, or conceptual abstractions, that represent the essential concept underlying the module. Go To Page: 1 2
The copyright of the article The Design Recovery Process (1) in Software Re-engineering is owned by . Permission to republish The Design Recovery Process (1) in print or online must be granted by the author in writing.
|
|
|
|
