Variable Message Format
Test Tool (VTT) Modernization ..........................................................................................1
October 2007 ........................................................................................................................1
CECOM Life Cycle Management Command ......................................................................1
Software Engineering Center (SEC) ....................................................................................1
1.Abstract .............................................................................................................................1
2.Introduction .......................................................................................................................1
3.Preparation for Conversion ...............................................................................................2
4.The Conversion Process Using the JANUS Toolset .........................................................2
4.1.Set-Up ........................................................................................................................3
4.2.Legacy Documentation ..............................................................................................3
4.3.Transformation ...........................................................................................................3
4.4.System Integration .....................................................................................................3
4.5.System Testing ...........................................................................................................3
4.6.Automatic Re-factoring .............................................................................................4
4.7.Semi-Automatic Re-factoring ....................................................................................4
4.8.Engineering Support ..................................................................................................5
4.9.Final Documentation ..................................................................................................5
5.Lessons Learned................................................................................................................5
5.1.Performance Description ...........................................................................................5
5.2.Budgeting ...................................................................................................................8
5.3.Scheduling .................................................................................................................8
5.4.Technical ....................................................................................................................8
6.Summary ..........................................................................................................................9
i

By Giang Ngo
U.S. Army Communications-Electronics Life Cycle Management Command (C-E LCMC)
Software Engineering Center (SEC)
Ft. Monmouth, NJ 07703, USA
Phone: (732) 427-0100 Fax: (732) 532-3398 giang.ngo@us.army.mil
The Software Engineering Center (SEC) owns and maintains a large volume of missioncritical, legacy software systems that are difficult to support and susceptible to security risks. A manual effort to redesign, develop, and deploy legacy software systems, potentially overwhelms
SEC’s resource planning and budgeting. The following issues affect these legacy systems’ supportability and maintainability:

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” 1 )

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.
1 “Windows Forms” is a general user interface (GUI) that replaces the old Microsoft
Foundation Class (MFC)
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
1

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 eventdriven 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 objectoriented languages, C++ and Java.
After a careful assessment of risk, schedule issues, and budget issues, SEC abandoned their
2 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 refactoring 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.
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.
TM
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
3 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.
4.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).
4.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.
4.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.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.
4.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.
4.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.
4.7.
Semi-Automatic Refactoring
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 semiautomatic 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:
4


The C++ STL strings replaced TSRI-type 2 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.
4.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”.
4.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,
2 C++ representation of Ada string structure
5 data element tables, and hyper-linked source code in an HTML format that represented the structure and flow of the VTT software system.
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
5.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-forline 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 refactoring 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.
40
35
30
25
22.9
20
19.3
15
14.5
13.2
10 5.0
4.0
5
2.5
2.5
2.0
3.4
4.0
3.3
3.3
2.4
2.5
2.2
0
Validate
Un con ve rte d
Import
Co nve rt ed/
No
R ef ac tor in g
Co nve rt ed/
Au to ma
Convert Encode
Co nve rt ed/
Re fa ti c R ef act or in g
On ly ct or ing
C omp le te
Figure 1.
3 VTT Response Time Before, During, and After Code Conversion Process.
3 Validated, imported and converted results were based upon one-thousand seven-hundred messages JITC test messages. Encoding builds a virtual display that is used to test the VTT GUI and to log test results., Encoded measurements were based upon ninety messages
6

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
5.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 refactoring 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.
5.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.
5.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.
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.
Schedule
Level of Effort
Cost
In House Development
24 Months
2.5
$ 625 K
Leverage on TSRI Capability
8 Months
0.4 Staff Year for SME Support
Total: $537 K includes
On Contract
SME Support
L-3 Overhead
Government’s Overhead
Travel and Equipments
Table 1.
8