Latest issues
Applications & Databases
Home >
Applications & Databases > Automation vs. Quality in Application Modernization
 SUB DEPTS
Print this article

< Previous Page 1 2 3 4 5 6 7 8 Next Page >
ASG

Automation vs. Quality in Application Modernization



by Mike Oara
November 1, 2007

Partial transformation steps: Sometimes, it’s recognized that a nearly 100 percent automation is either technically impossible or not economically feasible; however, a partial automation is still attractive. Data model transformation is always easier. Data manipulation statements are easy or difficult to translate, depending on the differences in databases (VSAM to relational is relatively easy; Codasyl to relational is more difficult). Some vendors provide language translation that works fine for purely algorithmic code that doesn’t involve data access or user interface interaction. 



Model-Based Transformation

Code transformation has inherent difficulties that are multiplied when the gap between technologies is larger. Model-based transformation is another approach in which some of these difficulties are overcome by abstracting the technical details of the legacy implementation and focusing on essential application functionality (see Figure 5 at the bottom of the page). In model-based transformation, an analyst uses a specialized tool to extract a model that describes the current application functionality. This is neither a purely automatic nor purely manual effort, but a “tool-assisted” effort. 

The extraction lets the analyst use the legacy application as raw material, select aspects to be extracted, and automatically convert them to model artifacts. This is quite different from building the model from interviews, manually drawn diagrams, or code listings. The advantage of a tool-assisted model is that the analyst digests the information and ignores incidental details, retaining only those aspects of high interest. The resulting model has the human touch, which makes it comprehensible and useful for the next phases. 

Once a model is extracted, it may be immediately used to generate artifacts in a modern technology-based application or it may be further refined by adding new functionality or implementation details that reflect the target architecture. 

The last step is generating the new implementation artifacts. Going from model to code is a classic exercise that multiple software tools support. This step is often automated to a high degree and delivers excellent quality, as the generated code tends to be well-organized, predictable, and standardized. 

In the model-based transformation approach, the quality issue is non-existent or minor, for two reasons: 

• Incidental technical details of the source application are already abstracted out

• Generation from a well-designed model usually results in clean, efficient code. Figure 6 (at the bottom of the page) compares code transformation and model-based transformation.


< Previous Page 1 2 3 4 5 6 7 8 Next Page >
This article has no comments. Be the first to comment!
 COMMENT ENTRY
Name:
Email:
Location:
Website:
Comments:
Remember my personal information
Notify me of follow-up comments?
Please enter the word
you see in the image below:
   
 SPONSORS
 SEARCH DEPTS
 MAINFRAME JOBS
Mainframe Programmer (CACS) Collections
USAA:A/c,IT,Marketing,Other
San Antonio, TX, US
Mainframe Programmer
General Dynamics Information Technology
Towson, MD, US
Mainframe Programmer
TSR Consulting Services, Inc.
New York, NY, US
Mainframe Programmer
HP
Baltimore, MD, US
Mainframe Developer (Cobol, PL1, JCL)
USAA:A/c,IT,Marketing,Other
San Antonio, TX, US
Mainframe System Programmer
General Dynamics - IT
San Mateo, CA, US
Mainframe System Programmer
General Dynamics - IT
Eagan, MN, US
Technical Associate - Mainframe Programmer
Charles Schwab
Phoenix, AZ, US
Mainframe Computer Operator
100-DST Systems, Inc.
Kansas City, MO, US