X hits on this document

404 views

0 shares

0 downloads

0 comments

83 / 120

software applications. Typically, COBOL programs have a single entry point, which

makes the process of identifying reusable methods all but unnecessary because, instead of

declaring multiple entry points, it is general practice for legacy COBOL programs to

include functional discriminators in their I/O data structure(s) that indicate the desired

action(s) to be taken by the program on behalf of the caller. For example, a field called

“TRANSACTION-TYPE” with the possible values “DEP”, “WTH”, and “BAL” would

serve the same purpose in a COBOL program as the methods “doDeposit(δ)”,

“doWithdrawl(δ)“, and “getBalance(δ)” would serve in a Java program.

Figure 9.2. Mapping legacy functional discriminators to an object-oriented design.

Fig. 9.2 illustrates how a functional discriminator in a legacy COBOL data structure maps

to modern programming strategies such as object-oriented design.

In a real-world situation, we would be looking to reuse legacy components whose

machine code is the result of thousands of lines of high-level language statements

(COBOL) that implement a particular business process. Instead of going through the

error-prone process of rewriting the legacy component, which is likely decades old, we

wish to reuse and reengineer it so that it is easily consumed by modern programs and

75

Document info
Document views404
Page views405
Page last viewedSun Dec 11 13:11:09 UTC 2016
Pages120
Paragraphs2913
Words25794

Comments