This phase focuses on doing real work. Now that you have a panoramic view of the available technologies and techniques, start modernizing the application.
Keep in mind the iterative and incremental nature of the modernization process, so start step-by-step in a way that makes sense for your situation. Divide the application into small units that you can modernize one at a time, but do not lose the whole view of the application.
The following sections describe some of the activities that you should consider in this phase.
Building your sandbox
Many modernization projects run in parallel with other business projects, so it is important that you build a sandbox that is specific for your project, where you can be sure that you are not affecting someone else's work and that no one else is affecting your work.
When you design and build your sandbox, remember to consider the following elements:
Copy all of the application objects to your sandbox, including, at the least, data areas, programs, service programs, user spaces, data queues, and any other object that your application is going to need to run in an isolated environment. To help you build the sandbox, create the application structure diagrams, which can be generated with automated tools.
In addition to the executable objects, make sure to have all of the tables that interact with your application. Isolate the data to allow changes to be made without affecting other projects. You should develop a method for restoring your sandbox data to its initial state in an automated fashion, which helps you run repeated test scenarios and automate testing. Always journal your sandbox data. Journals are indispensable when debugging your changes.
You need a complete set of tests to ensure that your modernization work is going in the planned direction. Your sandbox should contain a test set that you can run multiple times and easily. Without tests, any change can be unrecoverable.
In the first iterations, you must have a set of regression tests. As the project advances, your understanding of the application increases, enabling you to write specific unit tests.
Make sure that the test set covers all parts of the application that you are changing to ensure the “do no harm” approach.
Understanding the application
In every modernization project, you should take time to understand the application with which you are dealing. The level of understanding of the code that you need depends directly on the modernization approach that you select. Consider the following techniques for code understanding and apply them to your situation accordingly:
Compilation of existing documentation
It is likely that there is no documentation of the original application. Do your best to compile every piece of documentation that is available. Some useful documentation might include the following items:
– Deployment and configuration notes
– Incident history
– Test cases
Code reading sessions
The most basic technique to understand the code is to read the code. You must read the code that you are working on with your team, and look for repeated code and logic.
Initially, reading the code does not appear to be helpful, but after you become familiar with it, things become clearer.
Ask the experts about the business functions that are implemented in the code and keep in mind those functions while reading the code. Sometimes it is easier to understand the underlying business process than the code that implements it.
Debugging the application with specific tests can help you understand the application and how every module works. The usage of modern tools, such as Visual Studio or IBM Rational Developer for i, makes the debugging sessions more productive.
This is the analysis of the source code or the compiled object without running it. Usually, the static analysis has the following components:
Usage of code analysis tools
There are several tool providers that have specialized tools to review and help you analyze your monolithic programs. The Rational ARCAD Power Pack provides the Observer tool, which can help analyze code.
Extraction of business rules
Business rules refer to the business logic that is embedded in the code. Many tools help you extract this type of data from the code, which can help you understand the functionality that is implemented in the program.
Dependency analysis between components
Refers to the identification of relationships between the modules of the application. The diagram that is generated can help you understand how one component integrates with the whole application.
Internal structure diagram
Most legacy applications are large, monolithic programs. To easily understand the flow inside these programs, some tools can generate call diagrams between internal subroutines and subprocedures, such as the ARCAD Observer tool.
Complexity and maintainability metrics
Complexity and maintainability metrics can help you diagnose the section of code on which you are working and measure your progress. They can also help you estimate the amount of work that is needed to modernize.
These types of analysis are most easily done through the usage of automated tools.
This type of analysis is performed by tracing the running of the programs in a specific environment. There are many uses of the results of the dynamic analysis:
Traditional applications usually contain “dead code”. This is code that is not run but is still in the program. To identify code that is no longer needed, you can use a tool that helps you calculate how much code is covered with a set of transactions and how much code is possibly dead.
Dynamic call diagrams
The preferred way to understand how the program works is by monitoring its behavior while running. Dynamic analysis tools usually provide data that depicts the execution flow of a program, subroutines, and subprocedures.
To be effective, the dynamic analysis requires a good set of tests to produce an interesting result.
When your sandbox is prepared and you have a better understanding of the application, you can start doing modernization work. Here are some of the common tasks that you can do in this stage:
Cleaning the code
Cleaning the code
Cleaning code is the removal of elements that make the code hard to understand. Here are some of the things that must be considered when you clean your code:
– Removal of duplicated code.
– Conversion to a more readable form. In the context of RPG, this means converting it to free format.
– Removal of unused variables and procedures.
Restructuring the code
After you clean the code, you can extract related business logic of service programs that can be reused in different parts of the application. There are several good tools that are available to help you identify and restructure your code. Here are some tasks that you can
do in this step:
– Extraction of similar logic into reusable components.
– Encapsulation of global variables.
– Conversion of subroutines to procedures.
– Renaming of variables and subprocedures to more meaningful names.
– Writing self-documenting code.
Every module must contain only functionally related subprocedures and every service program must contain only functionally related modules. You must separate monolithic modules and organize the procedures into new modules. Every module must have one responsibility.
Modernizing the database
Data base modernization is a complete modernization model by itself. Later in this book (Chapter 9, “Database re-engineering”), you find a methodology that guides you through the process for this modernization.
After you modernize the application, make sure that all of your tests are successful. If your tests are not successful, you should not continue with the modernization process. You must ensure that everything is working as before and that you are not breaking existing functions