15.2 Structural Analysis

The structure and dependencies of the legacy system must be analyzed to determine a reasonable, if not optimal, program element migration plan. The call graph in Figure 15-1 illustrates how this might be accomplished.

Figure 15-1. Call graph

Figure 15-1 contains four kinds of program elements:

Root program elements for example, program element 418call other program elements but are not called by any. Root program elements are invoked directly by the user or an external process. By themselves , these program elements may not be good candidates for modernization because they call other program elements. This means that the modernized Java components would have to call back to the COBOL system.
Node program elements for example, program element 123both call and are called by other program elements. Node program elements share the difficulty of root program elements but also require creating adapters in the legacy code so that the remainder of the legacy system can continue to function without modification.
Leaf program elements for example, program element 412are called by program elements but do not call any. Leaf program elements are the best candidates for migration: They do not call back to the COBOL code, and it is possible to minimize the number of adapters required by migrating entire subtrees in a single increment. The shaded area in Figure 15-1 shows where three program elements can be migrated , requiring only a single adapter.
Isolated program elements for example, program element 435neither call nor are called by other program elements. Many of these isolated programs are reports . Independent of other issues, isolated program elements can be migrated easily. These elements could be used as filler in any given increment because they neither increase nor decrease the number of adapters needed.

Initially, we assumed that we could use a COTS COBOL analysis tool to generate a call graph for the legacy system. The RSS team had already acquired a well-known analysis tool. Unfortunately, this tool was not able to identify the majority of call dependencies in the legacy system. These calls were made by moving the name of the program to call into a variable and then calling the value of the variable:

 MOVE 'NGV129' PROGRAM-TO-CALL  CALL PROGRAM-TO-CALL

This is a relatively simple example of this problem. In other cases, the name of the program to call was established at runtime by concatenating the value of a variable to the end of a static string. In the end, we used a combination of static analysis, dynamic analysis, and manual code inspection to develop a complete call graph.

Initial Plan

To generate call graphs from the available input, we developed a tool that used the Rational Rose Extensibility Interface (REI) to create UML diagrams. The System Analysis and Migration tool (SAM) converts program elements to classes and converts calls to associations. Each association is labeled with its call type, that is, Perform, Call, Copy. There are a total of 900 distinct program element names and 10,629 calls. Figure 15-2 shows the resulting UML diagram.

Figure 15-2. Initial Rational Rose model

The initial Rational Rose model was obviously too complex to be useful. (It also exemplifies how some tools work well on simple problems but are unable to scale to real systems.) To simplify the model, we created a separate diagram for each root element. We also eliminated self-referential elements and reduced utility functions, which typically fetch, delete, or update a database record, to comments in caller program elements.

The result was more comprehensible. A series of charts was generated and then analyzed. Our two primary findings from this analysis involved isolated program elements and root program elements.

RSS has a total of 96 root element diagrams. Their complexity varies from 2 to more than 100 elements; however, most range from 2 to 20 elements. Figure 15-3 shows an example of a relatively complex root element diagram.

Figure 15-3. Root element diagram

The algorithm that we developed to generate the root element diagrams has some interesting features. Subtrees, for nodes within the diagram, are expanded only once in the model. This missing complexity is captured in two ways: It is recorded in the documentation for the program element class and is displayed using a shade of blue in the diagram. Darkening shades of blue indicate increasing numbers of reachable elements. Reachable elements are program elements that can be called, either directly or indirectly, by the program element, even if all those elements are not explicitly represented.

The documentation for each program element class contains the number of diagrams in which the class is includedroot elements are included in only one diagramthe number of times that the program element is called, and the number of program elements that are called. The number of program elements in the tree is the same as the number of reachable elements. As stated earlier, calls to utility functions are reduced to comments and also included in the documentation for each program element class. Figure 15-4 shows a sample of the documentation that is provided for each program element class.

Of the 900 overall program elements in RSS, 248 are isolated program elements, which can be ported easily with little impact; that is, they do not require adapters. However, many of these program elements are reports. Reports are a special case because they do not use component interfaces and depend on the database structure. As a result, it may make sense to identify program elements that are reports and to defer implementing them to the final data migration phase. Because these reports operate against the legacy database, they can remain unchanged until that time.

Figure 15-4 Program element class

 NUMBER OF DIAGRAMS: 1 TIMES CALLED: 0 TIMES CALLER: 4 NUMBER OF PROGRAM ELEMENTS IN TREE: 14 NOTES: accesses: GVPRGETPCT ... accesses: GVPRCALLER accesses: GVPRCNF added to diagram: NGV227 expanded in diagram: NGV227

Although analyzing root program elements teaches us something about the structure of the legacy system, it is not clear that root elements form the best candidates for componentization. In RSS, root elements map directly to user-level transactions. Business objects, on the other hand, are often built as augmented encapsulations of data entities. Consequently, components in the modernized system are more likely to correspond to the legacy data entities than to transactions. If we followed the root element approach, every diagram represented in the UML models would map to several business objects in the modernized system. This would create an unwanted complexity because multiple business objects in the modernized system would be in development at the same time.

Revised Plan

As we had concerns with building a code migration plan around root program elements, we conceived a new approach: building the plan around database records. This approach consisted of the following steps.

Arrange data records into as many sets as there are increments five in the case study. Group logically related records together to modernize related functionality.
For each data record set, group program elements that reference or depend on the database records.
For each data record set, identify program elements outside the group that invoke programs inside the group; these program elements potentially require adapters.
For the system, determine the modernization order for the groups created in steps 2 and 3 to minimize the number of adapters that must be built and balance the size of increments.

We further reduced system complexity and improved the quality of the migration plan by eliminating database records and program elements that were likely to be eliminated in the modernized system. For example, we eliminated database records that were used to maintain global constants or information about the systemfor example, the number of user terminalsbecause this information would be managed differently in the modernized system.

Once the database records were grouped, we ran them through the tool and analyzed the results. If these results were acceptable, we could tweak and execute the plan. If the results were not acceptable, we could reorganize the records and run the tool again. Figure 15-5 illustrates this revised process.