Effort. skill. purpose of the of. assets that are. accessible to. management. stand alone. PBSI Whitepaper. Copyright 2011,

Size: px

Start display at page:

Hester Stone
8 years ago
Views:

1 The role of Code Visualization in a Migration Effort Synopsis: Replatforming legacy IBM i application code Microsoft.NET requires specialized skill sets that encompass knowledge of both the legacy and target environments. Simplistic migration efforts that convert individual legacy programs in isolation are naïve at best and may result in unusable and unmaintainab ble systems. Before starting any migration effort, PBSI recommends the use of their world class code visualization technologies more fully understand the architecture and scope of the original assets, and develop a meaningful architecture for the newly migrated application. Code visualization is an emerging technology that hass proven its usefulness in understanding complex systems. Aumated visualization ols, suchh as the PBSI ScatterGraph, are especially important when working with legacy IBM i code assets, where documentation may be absent or in non machine readable form. If documentation is available for the legacy systems, it is an important adjunct the visualizations that are provided by the ScatterGraph. PBSI uses its ScatterGraph as the first step of its.netigration technology replatforming process provide comprehensive drill downs in systems, subsystems, programs and functions within programs. When used evaluate a legacy IBM i application, the primary purpose of the ScatterGraph is clearly show how systems are organized, where there is reuse of assets across systems and subsystemss and help identify assets that are no longer in use. The ScatterGraph is fully interactive. Highly qualified personnel who are conversant with both the legacy environment and.net can tag items thatt are depictedd on a ScatterGraph. Some examples of tagging include categorization of assets, flagging an asset as deprecated, indicating assets that are candidates for replacement by superseding technologies and identifying assets that are be included in a code migration effort. Data captured by tagging is kept in a Microsoft SQL Server database that is used by the ScatterGraph oling and is accessible other ols. Data produced by the legacy source code analysis ols and captured during tagging can be further studied with SQL Server Reporting Services. Such analysis reports are readily available via Microsoft Team Foundation Server and Microsoft SharePoint Server 2010, whichh is used as a portal environment for project management. Why the ScatterGraph is important Virtually all object oriented development environments and frameworks support the organization of code in packages or namespaces. This is in contrast the IBM i code development model, whichh hisrically consisted of individual stand alone programs that could be called independently or from other programs. A straight acrosss conversion of IBM i programs stand alone Windows executable files (exe files) would result in a system that would be at best cumbersome and at worst unusable. 1

Simplistic migration efforts that convert individual legacy programs in isolation are naïve at best and may result in unusable and unmaintainab ble systems.

2 Rather than attempt provide straight across IBM i code assets interact with each other. The ScatterGraph, shown in Figure 1, shows how and where programs are used within a subsystem. When applied a system level view, the ScatterGraph can be usedd examine cross system interactions, conversions, PBSI uses its ScatterGraph oling clearly show how existing help identify highly reused assets. Figure 1: This is a view of the ScatterGraph (center panel). It shows a visualization of a program call stack. An important goal of the ScatterGraph is identify highly reused components so that those programs can be migrated in the same resulting.net assembly (typically deployed as a Windows Dynamic Link Library, or DLL). In IBM i programming terms, this process is similar identifying code that can be compiled in a service program. The benefits of identifying and migratingg highly cohesive IBM i assets in well architected assemblies include ease of migration, ease of testing and verification, ease of deployment and security and ease of maintenance. 2

assets. Figure 1: This is a view of the ScatterGraph (center panel). It shows a visualization of a program call stack.

3 Figure 2 showss a magnified view of the ScatterGraph. Using the magnified view, a.netigration architect can easily review the structure of the legacyy application.. Using the tagging capabilities of the ScatterGraph, the architect selects assets that are be grouped in.net namespaces and projects for use in Visual Studio. The tagging capability supports individual item selection, multiple selection, lasso selection and drag and drop selection. Figure 2: This magnified view of the ScatterGraph shows how individual legacy IBM i assets can be clearly identified and selected for tagging. 3

. Using the tagging capabilities of the ScatterGraph, the architect selects assets that are be grouped in.

4 Relative Size View In addition the program relation views shown in Figures 1 and 2, the ScatterGraph provides the Relative Size View, shown in Figure 3. The Relative Size View provides a high impact visualization of how legacy assets are ranked in relation variouss weighting facrs that are selected while using the view. An easy understand Relative Size View can be based on the number of lines of executable code that are contained within the original source. Given that weighting facr, it would be easy see from Figure 3 that there are four quite large programs, followed by about a dozen smaller programs and finally a set of much smaller programs. Although program size is an important metric and is often used when estimating migration efforts (the lines of code, or LOC, measure), large size programs may in fact contain lengthy sequences of trivial operations (for example, simple field initializations or movement of database fields in and out of the program). The Relative Size View can be meaningfullyy paired with the Program Analysis Graph, shown in Figure 4. Figure 3: The Relative Size View provides a visualization of how legacy assets are relatedd in terms of weighting facrs derived from analysis of the assets. In addition providing a visual evaluation of lines of code, some other metrics that can be usefully explored with the Relative Size View include: : Number of database files used in a program. Number of IBM i API calls that are included inn a program. Number of workstation file record formats used in a program. Usage of legacy operation codes. For example, many IBM i program assets were originally coded for the IBM System/36, System/38 and other earlier systems. Identification and remediation of the legacy operations before starting the migration process can yield a better result. 4

An easy understand Relative Size View can be based on the number of lines of executable code that are contained within the original source.

5 Program Analysis Graph In addition the other graph types, the Program Analysis Graph shown in Figure 4 is used help understand a legacy program before beginning migration. Ass shown in the figure, the graph shows the structure of an IBM i RPG program, with its use of database files (yellow icons), its display file (green icon), subroutines (blue icons) and external calls (red icons). Using this graph, the.netigration architect can quickly review the structure of a legacy code asset without necessarily needing view the actual source code. This view helps the architect understand frequency of use patterns within the program. For example, the external call shown in the diagram with the most connections will be of special interest in terms of understanding how the application works. Another very useful data point that can be seen on the Program Analysis Graph is potential dead code. In RPG terms, dead code is frequentlyy contained in subroutiness or procedures that are not called from any other subroutine or procedure in the program. The potential dead code would be depicted on the graph as an icon with no connections it. However, even if the item is depicted as dead code, the skills of the.netigration architect are still required make the final determination as how handle the item. The RPG language allows for creation of specific subroutines that are not directly called by other code in the program, but may be called by the runtime environment. Also, many RPG programmers originally put initialization code in non executable subroutines. For those reasons, the Program Analysis Graph is used as a starting point determine what code may be candidate codee omit from the migration. Figure 4: The Program Analysis Graph shows the internal structure of a legacy program and helps identify highly used code, external calls and potential "dead code". 5

calls (red icons). Using this graph, the.netigration architect can quickly review the structure of a legacy code asset without necessarily needing view the actual source code.

6 Summary At PBSI, we believe that the only viable technique successfully migrate legacy IBM i code assets in.net is determine, prior starting the migration, where and how the migrated code assets will fit gether. When developing new systems of any meaningful size in an objecriented environment, this analysis work precedes any coding activities. The ScatterGraph, its visualizations and its database outputs and reports provide the basis for review, planning, migration tracking and deployment of the migrated asset. In a large scale replatforming migration, it is a given that there will be code produced as a result of the migration. The job during migration is retrofit an object oriented structure, and more particularly, a.net oriented structure, around the existing code so that it can be meaningfully brought forward in the new environment. Any proposed solution that does not address those issues is suspect, as it is our belief that a one for one migration of IBM i programs individual Windows EXE or DLL files yields a suboptimal result. For More Information Natalie (Kilner) Hughes President and CEO Packaged Business Solutions, Inc. (800) nataliek@pbsilink.com The Role of Code Visualization in a Migration Effort 6

When developing new systems of any meaningful size in an objecriented environment, this analysis work precedes any coding activities.

tions Synopsis: User suitable for chart that is be considered that consider Organizations high volume applications may i applications.

tions Synopsis: User suitable for chart that is be considered that consider Organizations high volume applications may i applications. A Comparison of User Interface Migrated Legacy Applicat tions Technologies for use in Synopsis: User interface modernization of legacy IBM i applications is most often consideredd in terms of getting the