外文翻译逆向工程过程在真实情况中的应用的分析Word下载.docx

1、Finally, the problem of the efficacy of the tools used to obtain the reverse engineering products was made evident during the experimentation on the field.1: Introduction We present an experience in which process qualityand product quality interact and mutually improve one another. The process is re

2、verse engineering while the product is the documentation of programs necessary to exploit the program better. The salient point to be gained from the experience are, in general, the model as it appears after improvements stemming from trial on the field and, in particular, the method for integrating

3、 static and dynamic analyses to improve the process. The paper describes the application of a process model to a real situation. The scenario is a set of programs with the following characteristics:language:COBOLoperating system:BS2000total no. of programs:653no. of on-line programs:348no. of batch

4、programs:305no. of files:70no. of data:9 000no. of Instructions:900 0002: The reverse engineering process Our reverse engineering process had two main objectives: （1） to increase the ease of maintenance of the software system, and （2） to improve its usability by the final users and the ease of knowl

5、edge transfer among different users 5. The first involved reconstruction of the project design documentation and restoration of the most degraded arts while the second required reconstruction of the user documentation and the data conceptual model. This elps users to understand their own information

6、 system etter from the point of view of the data processed 4,6. Figure 1 shows the process model, which is briefly described underneath. Further details may be obtained from 10. 1. Inventory Software System. The following cross references are extracted from theold software system:call dependence X-r

7、ef, copybook X-ref, and file access X-ref. 2. Reconstruct Logical Level of Data. From the data description, the hierarchical structure constituting the logical data model is reconstructed. The aliases are recognizable entities in the application domain. Figure 2 shows a record declaration, as input

8、to the phase, and the relative hierarchical diagram, as output from the phase.The arrows represent the hierarchical relationships between the substructures in the record; elementary data are not shown. The data are classified as application domain data, control data, and structural data.Application

9、domain data are the attributes of recognizable entities in the application domain. For example, the field named MT02-02 representing the amount is also an attribute of MORTGAGE and is therefore recognizable in the application domain.Control data have no correspondence with the application domain but

10、 are used to record the occurrence of an event during the execution of a program, so that other programs can adapt accordingly; flags validated by one program and used by others, asynchronously, to determine their behavior according to the previous history of the software system, are typical example

11、s of control data. For example, the field MT02-33 is preset to indicate the existence of an agreement for taking out the mortgage, which must form the basis of the variation in interest rate to be applied when calculating the instalment; it is a typical example of control data.Structural data are da

12、ta necessary for managing the organization of data bases or files. The field MT01-05 is a typical example of structural data, because it identifies the record type inside the MORTGAGE file. 3. Abstract Data. All the data in the application domain which belong to the logical model and are not dead ar

13、e associated with the corresponding meaningful concept for the application domain 1. 4. Analysis of Existing Information. This activity involves identifying the expected functions in the program being reversed using two types of information.The first is static knowledge, i. e. the internal and exter

14、nal documentation of the rules governing the application domain of the function. The second is dynamic, derived from the experience of the programmers and users who interact with the working programs.Figure 2. Input and output of Reconstruct Logical Level of Data phaseFigure 3. Equivalence test of t

15、he system before and after reverse engineering 5. Reconstruct Logical Level of Programs. Each program is associated with a structure chart in which each module corresponds to a SECTION or an external subroutine of the program. In this phase, both dead data and dead instructions are identified. These

16、 are data not used by the program and instructions which cannot be run, respectively. The former are communicated to the Abstract Data activity while the latter are erased from the structure chart , which thus constitutes the logical model of the functions. 6. Restore Logical Model. Restoration invo

17、lves introducing changes to improve the structure of the programs and make them easier to maintain, without causing repercussions on the data or interfaces with other systems. Some examples of modifications are renaming of variables, making their identifiers more meaningful; extracting modules with

18、high internal cohesion from those with low cohesion and isolating them in the structure （7, 8, 12, 13）; externalizing modules which, in the present process, are in line with the main;localizing variables declared to be global but used locally in both existing modules and in processes extracted durin

19、g restoration. Execution of these activities is facilitated by the expected functions derived from the phase of analysis of existing information. In fact, thanks to this knowledge, the operators can extract the functions from the modules present in the logical model. This makes the logical model mor

20、e readable and its modules less complex. 7. Abstract Functions. The functions abstracted during restoration are documented. The aim of each function is described in textual form. The relationships between functions are also documented by means of data flow diagrams. The latter, together with the des

21、cription of each function, constitute the conceptual model 9. The reverse engineering process is not symmetrical because the programs are restored while the data are not,because any interference with the latter would affect the procedures and make the whole restoration process very expensive. In fac

22、t, restoration of the programs is confined to the instructions of each single program, a much simpler and more economical process. The reverse engineering process described modifies code, so that it is necessary to verify that the working programs are equivalent to those produced by the process. A t

23、est process is used and, as the only reliable component in the working system is the code in question, it is only possible to test the equivalence between the actual and the reversed program. Test cases obtained during normal working of the actual system are used. The equivalence test is modeled in

24、Figure 3.3: Operative resultsThe planned process was put in production in the scenario described earlier and after seventeen calendar months of work on a production line, the first results were obtained. It should be noted that a production line refers to an organizational unit which has all the res

25、ources required for executing the process autonomously. In this case, the production line is composed of eight reverse operators and one reverse engineer. The former execute theprocedures according to the defined process models while the latter coordinates activities and takes all the decisions nece

26、ssary for solving all indeterminate points in the execution procedures. The production line shares an expert in the application domain with other organizational units in the company. These first operative results can be analyzed from the point of view of both efficiency and efficacy. Although effici

27、ency was not the main aim of this work, the data on the activities for reverse engineering of the programs and of the data are summarized in Tables I and II,respectively. Two important considerations can be made. The productivity of the operators for reverse engineering the programs is correlated wi

28、th their experience in the application domain; this explains the differences seen in Table I. In reverse engineering the data, the difference in productivity has less correlation with experience because there is very little automation of the activities and so the man time required is very high in an

29、y case. The second point is that commercially available tools are often inadequate for large projects. For example, the tool used in extracting the data structure becomes unacceptably slow when access to previously inserted information is required, if the data are more than a thousand or if access is to an entity with more than one hundred attributes. The tool used for the programs, on the other hand, shows an abrupt drop in performance （answers to questions on data and control flow slow down） as soon as the threshold of 80