Extracting the Structure
The third step is to begin recovering detailed design from the source code. This step involves two tasks: extracting the calling hierarchy and expressing it as a structure chart, and recording information about data exchanged between nodes in the chart. The recovered information can be recorded using the structure chart editor and the data structure editor in the software development environment.
While creating the structure chart, the main program routine or procedure or function becomes the top node or the root node in the chart. For example, in case of a C program, the function main( ) becomes the root node of the structure. Routines/Procedures/Functions called by the main function are represented by the second layer of nodes in the structure chart. Thus, each node in the structure chart corresponds to a subroutine, function, procedure or a library routine in the program. For each node, sub-nodes are added if the corresponding routine/procedure/function calls to other routines/procedures/functions. This is done until the leaf nodes are reached. Leaf nodes correspond to the routines/procedures/functions that call no other routines/procedures/functions or library routines.
Creating structure charts from the source code should be automated. The structure chart captures the calling hierarchy of a program and must contain all the cross-reference information within the program. The intent is to capture this information at an implementation language independent level. This could be achieved by giving the routines/procedures/functions or library routines, the names that are easily intelligible by the viewer because that is the main purpose of reverse engineering. Therefore, if the names of the routines/procedures/functions used in the domain system are not understandable, then less implementation oriented names should be assigned to the nodes in the structure chart.
Along with recording the structure chart information, the data items passed between nodes should also be recorded. Structure charts must show the direction in which the data items are passed between nodes. Data item usage has to be analyzed to determine whether data items serve to carry input data, output data or both. Information about data items, such as purpose, data type, range of values, etc., should be recorded in the data structure diagrams. Similarly, here, the data items should be assigned names that are less implementation oriented and their data types should be mapped to more generic types such that they are easily understandable, so as to achieve language independence.
Go To Page: 1 2
