|
|
|
Now, after the extraction of the program structure and the creation of the structure chart for the program, the next step is to record the processing associated with each node of the structure chart. For the nodes that correspond to system or library routines, the explanation could be given in English or some other language. For the source routines, again, some language can be used but its better to record this information in more structured or formal manner. Therefore source routine processing steps can be recorded using a PDL.
There could be a lot of problems that may arise while recovering the functionality. As stated by E.J.Byrne, discussing the problems faced while recording the functionality of a Fortran source, "One problem was what to do about the debugging statements? The source code contained debugging statements that were guarded by conditional compilation directives. Were these part of the design? Probably not, but they were part of the operational capabilities of the software. Talks with the maintenance staff revealed that debugging statements were never used. Therefore, these statements were not recovered. This raised the issue about how to handle conditional compilation code. Generally, such code is selected based on the operating system, machine, etc. The conditional compilation code used here referred to differences between PDP-11 systems and MicroVaxes. The maintenance staff was again consulted and it was learned that the software would not be used on PDP-11 systems, so the conditional code was not recovered. This solved the problem for this case, but leaves the general question unsolved." A possible solution to the conditional compilation problem is to consider the purpose of the conditional compilation code. One use of such code is to handle functionality that must be implemented differently on different computer systems. Here, the functionality can be recovered and the systems differences can be ignored as an implementation detail. A more difficult case occurs when conditional compilation code is used to hold functionality that is implemented on one computer system and not on others, i.e. system dependent capabilities. Here, the design of the program differs depending on the intended implementation system. Another issue is where does the detailed design stop and implementation begin. There is a wealth of information in the source code that would not normally be recorded in a design. The problem is realizing what should not be recovered. For example, the source code contains a system routine that requires a parameter to hold a returned status value. In the code the variable used for this parameter is of type integer. Should the system routine be included in the detailed design? Should its calling interface be recovered exactly as given in the code? Should the detailed design declare the variable as an integer or as a design level type name? In the work done by E.J.Byrne, the system routines were recovered into the detailed design, which information, later on, was determined to be too implementation specific. A generic processing step should have been taken instead. Go To Page: 1 2
The copyright of the article Recording the Functionality of the Program in Software Re-engineering is owned by . Permission to republish Recording the Functionality of the Program in print or online must be granted by the author in writing.
|
|
|
|
|
|
|
|