• Lack of legacy language software management skills  

• Lack of  legacy language programming expertise

• Diminishing support and availability of  legacy software developmental tools

• Introduction of new, emerging technologies (i.e. “Windows Forms”¹)

• Increased maintenance costs

• Compliance with current army capabilities maturity model integration (CMMI) standards

   This paper describes an automated technique that converted the Variable Message Format (VMF) Test Tool (VTT) from Ada to C++. The metrics established by this project enable SEC and other organizations to better plan language conversion processes and to accurately estimate conversion project schedule and budget details.

2. Introduction

   The SEC initially planned to have its own staff manually convert the VTT code from Ada

to C++.  Given the limited manpower and budget, a plan was laid out that allowed portions of the VTT software to be recoded over a span of two years. The plan’s steps were as follows: 
 

• Identify functional modules of the VTT (e.g., parser, validator, file input/output, etc.).

• Restructure/Recode the existing Ada logic modules to make the functional modules Windows Dynamic Load Libraries (DLLs).

• Recode a functional module and make it a C++ DLL.

• Remove the Ada DLL and replace it with the C++ DLL.

   SEC software engineers started the conversion process and identified the VTT Parser as a candidate module for conversion.   
 

   During this time, SEC management discovered The Software Revolution, Inc. (TSRI), a company that specializes in converting code from one language to another.  Since 1995, TSRI has used the JANUS^TM Toolset to automatically convert legacy code to more modern languages with minimal human intervention. It should be noted that while the JANUS^TM toolset does produce code with minimal intervention, achieving system response time and code readability project goals still, required substantial human intervention.  
 

   TSRI had already successfully completed numerous other DoD code conversion projects. The processes that the JANUS^TM toolset used for the Ada to C++ conversion are applicable, but not restricted to the following legacy languages: COBOL, Assembler, CMS-2, FORTRAN, C, and VAX Basic. TSRI achieves this language portability by converting each source language to a proprietary pseudo-language representation. Finally, TSRI converts this pseudo-code to the target language.   
 

   The following is TSRI’s description of their transformational process: 
 

   The TSRI transformational process begins with the automatic identification of candidate classes and objects. These candidates are mapped into an Intermediate Object Model *IOM). The IOM model is a relatively complete transformation of the input source code into an IOM model that is consistent wit the structure of object-oriented C++. This transformation into the IOM form locates redundant, duplicate, and similar data processes, and abstracts those detected items into classes and methods. The classes, relationships, attributes, and operations of the derived IOM model conform to the Universal Modeling Language (UML) standards 
 

   The overall process for transforming from a procedural to an object-oriented application starts with input of legacy application programs, and produces as output a completely integrated and modernized system. The output system consists of object classes and their instances. These object class instances are complete with regard to data typing, methods and IOM processes (executable mission-oriented C++ functions, which refer to Class member element, and member functions or methods). These constructs possess a derived architecture and control structure methods associated with an object-oriented paradigm. The IOM application contains calls to derived methods associated with desired classes. 
 

   The design documentation extracted from the IOM model is a hybrid between conventional object-oriented modeling languages and event-driven programming models. The mapping from procedural code into object-oriented code is functionally faithful to the original procedural system. However, this IOM model follows the semantic and syntactic rules of the object-oriented languages, C++ and Java. 
 

   After a careful assessment of risk, schedule issues, and budget issues, SEC abandoned their manual conversion efforts and contracted TSRI to perform the entire conversion effort. The TSRI contract was “firm fixed price”, except for the semi-automatic re-factoring task.  
 

   Semi-automatic re-factoring is defined by TSRI as, “the identification of situations within the code where customer-provided Domain Experts could opt to make engineering changes to the system”. Since the time required to complete semi-automatic re-factoring was difficult to estimate, SEC contracted this task with TSRI using the “firm fixed rate” contract mechanism.  The difficulty in estimating the level of effort to be applied to this project occurred because at the commencement of the project it was unknown what re-factoring operations would be specified by the SEC. 
 

   The SEC conversion team consisted of a SEC project lead, a SEC subject matter expert (SME), and a SEC test engineer.  Prior to the conversion process onset, the SME provided technical support to TSRI staff in their planning phases. The SME provided support to TSRI in the set-up phase, explaining several obscure areas of the source code. 
 

   Prior to the integration phase, the SME analyzed the converted code and identified areas that could be re-factored. During the integration phase, the SME assisted TSRI by discovering misaligned pointers and by assisting TSRI to restore database connectivity. In the system integration phase, the SME concentrated his system testing on high-risk areas.  
 

   The SME prioritized the semi-automatic re-factoring effort so limited funds would be well spent. Budget constraints forced the SME to participate in troubleshooting and problem resolution during the semi-automatic re-factoring phase. Future projects should note that such participation helps ensure success as the system SME is familiar with all aspects of the code and can swiftly detect errors. 
 

   On the TSRI side, the significant players were as follows:

• the JANUS^TM tool

• TSRI staff knowledgeable in the source language

• TSRI target language expert.

   This document describes the successes and challenges of this conversion process methodology. The experiences encountered in this project may assist other government project managers with similar conversion projects to better estimate their cost and schedule.

3. Preparation for Conversion

      Ada-based VTT code was prepared for the conversion effort by the addition of a trace log.  The log recorded data exchange among modules and between modules and the database. The VTT database contains tables describing various VMF standard baselines. 
 

      A site visit was conducted by the SEC SME and the SEC project lead. The SME conducted a code walkthrough with TSRI personnel in attendance. During the code walkthrough, the SME clarified TSRI’s understanding of the VTT source code logic and identified, to TSRI, potential conversion problem areas.

4. The Conversion Process Using the JANUS^TM Toolset

   The conversion process using the JANUS toolset entails the following sequential nine steps:  
 

• Set-up

• Legacy documentation

• Transformation

• System integration

• System testing

• Automatic re-factoring

• Semi-automatic re-factoring

• Engineering support

• Final documentation

   TSRI identified only four steps as essential. These steps are set-up, transforming, system integration and system testing.  Subsequent challenges in system response made it clear that any conversion effort must execute all nine steps to assure comparable system response and maintainability.

1. Set-Up

Expectation: 
 

   The JANUS^TM toolset inputs legacy code with embedded comments and parses the legacy source code. No hand-editing shall be required in this step. 
 

Result: 
 

    TSRI successfully modified their parser and added rules to the JANUS toolset so that it properly mapped Ada source code to its intermediate object model (IOM).

2. Legacy Documentation

Expectation: 
 

   The JANUS^TM toolset produces a detailed presentation of the structure and flow of the legacy code. 
 

Result: 
 

   TSRI used JANUS^TM to successfully generate flow control diagrams, structure charts, data element tables, and hyper-linked source code in an HTML format that represented the structure and flow of the VTT software system.

3. Transformation

Expectation: 
 

      The JANUS^TM toolset translates, compiles and links legacy code into the target language. 
 

Result: 
 

      JANUS^TM toolset successfully transformed VTT source code into compilable and linkable C++ code with all external calls “stubbed out.” 
 

   JANUS^TM also automatically generated HTML-based documentation reflecting the legacy system’s design.  The documentation generated by JANUS^TM shows calling hierarchies; each variable’s use and type; and each module’s dependencies. 

4. System Integration

Expectation: 
 

   Converted code modules successfully reintegrate into a test-ready application. The working application contains an equivalent user interface, performs equivalent functions, and utilizes equivalent external hooks to the original legacy software package. 
 

Result: 
 

   VTT source code was successfully integrated into a “test-ready” application package.

5. System Testing

Expectation: 
 

• TSRI tests C++ VTT source code with SEC test scripts and with the Joint Interoperability Test Command (JITC) test plan.

• TSRI corrects errors revealed during testing.

• TSRI corrects any additional errors discovered by SEC.

Result: 
 

C++ VTT source code is free of errors and fully operational.

6. Automatic Re-factoring

Expectation: 
 

      System testing proves that C++ VTT source code is fully operational and free of dead and redundant code. 
 

Result: 
 

   TSRI utilized the JANUS^TM toolset to analyze the converted code and then identified and eliminated the dead/redundant code.  More than 15,000 lines (fifteen percent) of dead and redundant code were successfully removed from the source code. This improved overall system response time by a corresponding fifteen percent.

7. Semi-Automatic Re-factoring

   Semi-automatic re-factoring is the most crucial phase of the conversion process. During semi-automatic re-factoring, the SME identifies each area in the code that can be improved with respect to performance, maintainability, readability, and extensibility. The SME’s input was critical in this phase. 
 

   In this phase of the contract, reimbursement was “firm fixed rate” rather than “firm fixed price”.  The project manager needed to provide adequate advanced budget allocation and careful schedule-monitoring.   
 

   It should be noted that the schedule was most impacted by re-factoring itself, not by regression testing required in each phase of the re-factoring. Due to funding constraints, SEC conducted the second round of regression testing and most of the subsequent troubleshooting and error correction. 
 

Expectation: 
 

      Each semi-automatic re-factoring task must either remove superfluous and redundant code layers (i.e. function calls or generic classes) to ease maintenance; or must improve the code’s performance by utilizing the more efficient, built-in standard language libraries. 
 

      Regression testing follows each semi-automatic re-factoring task listed below. 
 

• VTT software equipped with C++ Common Language Infrastructure (CLI)

• TSRI compiles and executes VTT software from Visual Studio 2005 instead of Visual Studio 2003.

Result: 
 

• The C++ STL strings replaced TSRI-type² strings. 

• TSRI in-out templates were removed.

• The Microsoft Application Program Interface (API) replaced Boost Threads (third party library that provides a set of features that can be utilize across platforms) and other Boost dependencies.

• The Microsoft STL (third party library that implement C++ standard library) replaced the C++ STL port.
• The Ada translated, now superfluous, Win32 wrappers were removed. 
• The C++ comparable built-in data structure and TSRI customize pointers replaced Ada linked list structure. 
• A software switch permits VTT to run in the C++ Common Language Interface.  With the C++ Language interface, VTT makes use of the .NET environment that enables “just in time” compilation, thread management, exception handling, and garbage collection.

8. Engineering Support

Expectation: 
 

      TSRI provides prompt support as required. 
 

Result: 
 

      Funding exists, obligated prior to the conversion process. This support shall be delivered “on demand”.

9. Final Documentation

Expectation: 
 

      The JANUS^TM toolset produces a detailed presentation of the structure and flow of the converted C++ code. 
 

Result: 
 

   TSRI used JANUS^TM to successfully generate flow control diagrams, structure charts, data element tables, and hyper-linked source code in an HTML format that represented the structure and flow of the VTT software system.

5. Lessons Learned

   System response time issues required budget reprogramming and project schedule realignments. Recommendations for improved software project planning in future programs follow: 
 
 

• Set-up

• Legacy Documentation

• Transformation

• System Integration

• System Testing

• Automatic Re-factoring

• Semi-automatic Re-factoring

• Engineering Support

• Final Documentation

1. Performance Description

   The intent of the code conversion was “operational equivalence” to the original product; however the original wording of the task description was legally ambiguous and unclear to the contractor.   The phrase, “operational equivalency”, failed to clearly delineate all governmental operational requirements. 
 

Issues encountered: 
 

      Prior to semi-automatic re-factoring, the converted software’s response time was degraded by thirty-nine percent in comparison to the legacy software’s response time.  Line-for-line implementation of Ada’s data structures as non-native processes in C+++ produced inefficiencies in the following areas:  
 

• String Implementations

• Input/Output  processes

• Intermediary TSRI templates

• Intermediary TSRI function wrappers

      As expected, the performance of the converted code gradually began to improve as re-factoring progressed. Many modifications were made to the converted VTT’s string manipulations. Due to budgetary constraints, optimization of the I/O processes was never addressed.  
 
 
 

Figure 1.³ VTT Response Time Before, During, and After Code Conversion Process. 
 
 
 

Recommendation: 
 

      The Statement of Work (SOW) should specify the following details for each thread: thread inputs and outputs, thread response time, resource usage (e.g. memory, CPU, operating system resources), general user interface fonts/colors, etc.  These details in the SOW reduce the government’s risks

2. Budgeting

   Initial government cost estimates were unable to foresee the extent of semi-automatic re-factoring required to meet system performance speed objectives. In hindsight, SEC engineers have concluded that re-factoring time is a totally unpredictable process. Since this was a “firm fixed rate” type contract in the most critical task, and since the initial SOW did not specify system response times clearly, the government had to obligate additional funding to insure delivery of a usable product. 
 

Issues encountered 
 

      In this conversion process, due to the budget challenges mentioned in Section 4.2, troubleshooting and error correction were performed by SEC personnel, not by the TSRI. 
 

Recommendation 
 

• Perform comprehensive pre-conversion assessment/research. It can reveal potential tasks for semi-automatic re-factoring.

• Ensure that 20% to 25% of total project cost is allocated for the semi-automatic re-factoring phase.

• Plan on having a government SME involved in the re-factoring process, both in deciding on the re-factorings to be executed and in any follow-on troubleshooting.

3. Scheduling

Issues encountered 
 

No issues encountered. 
 

Risk mitigating action 
 

• SEC requested that TSRI add an additional two weeks to the test schedule before beginning re-factoring.  The extra test time reduced the risk of existing errors propagating into the automatic re-factoring phase.

• SEC closely monitored the re-factoring tasks to ensure the schedule was not delayed by any single task.

• SEC prioritized re-factoring tasks by comparing their technical risk with the benefit they bring.

4. Technical

Issues encountered: 
 

      SEC found a serious error in VTT during linked-list re-factoring.  The error was identified and corrected due to close collaboration between the VTT SME and TSRI’s personnel.  
 

Risk mitigating action: 
 

      The analysis was performed by personnel with expertise in both languages.

6. Summary

 TSRI’s automated code conversion system economically produced a faster, more maintainable, and more reliable application.  Availability of a capable SEC SME was critical to TSRI’s success in each and every phase. 
 

       Despite the success of this project and the quality of metrics generated, the scalability of the semi-automatic re-factoring effort is unclear. Semi-automatic re-factoring is an inherently unpredictable process.  Larger sized recoding efforts may scale in a linear manner or in an exponential manner. 
 

Reduced Risk: 
 

• Code conversion is TSRI’s primary business.   TSRI uses the JANUS^TM toolset, a mature automated conversion tool developed in 1995.

• TSRI’s process does not change the design or layout of the code.  JANUS^TM conducts straight translation from Ada to C++.  Therefore, SEC incurred no new developmental risks.

Shortened Development Time: 
 

 TSRI’s JANUS^TM conversion required eight months as opposed to the originally proposed manual conversion by SEC that required two years. 
 

Reduced Cost  
 

      SEC saved fourteen percent or $88,000 in conversion costs.  See Table 1. Since this savings compares actual costs to projected costs, true savings may be greater. 
 

Improved Maintainability: 
 

• Automatic re-factoring removed the obvious dead and redundant code.

• Semi-Automatic re-factoring removed redundant generic function call layers and replaced slow string and I/O manipulations with optimized C++ standard library calls.

No Added Manpower: 
 

      The conversion required no additional manpower.   
 

Documentation: 
 

      TSRI’s conversion process generated complete documentation of both the legacy and the converted code.  The documentation included calling hierarchy and list of variable type, location, and uses.  
 

Pilot program: 
 

      The time and money savings of this code conversion effort suggest that SEC model code conversion projects of comparable size and complexity upon this project’s successes. 
 
 

Table 1. Comparison Chart for In-house Development Versus Using TSRI