Project Analyzer is a program used to provide a high-level picture of the migration project and give an estimation of the migration effort. The tool efficiently collects core data critical for an accurate estimation directly from the source code of the Visual Basic application to be migrated.
We use the term ‘Precision’ to measure the accuracy and the extent to which the Visual Basic code is automatically converted to ASP.NET or Java. Repeatable errors are counted only once, i.e., they are considered as one unique error. The resulting precision is a value expressed in percentage that defines the number of well-formed lines of code versus the unique errors.
Having calculated the achievable Precision, Translation Studio will then identify and count the unsupported application components i.e. those elements of the application that Translation Studio is unable to convert without manual intervention. Examples of such components and situations are usage of external binary libraries or usage of Win32 API functions not available in a Java environment.
Using the precision together with the number of unsupported components and situations and multiplying them by known metrics for solving such situations inside your organization, an accurate migration time estimate is calculated. All this is done in a couple of seconds!
Furthermore, in conjunction with the core data used for the estimate, the tool counts incidences of any dead and semi-dead code. The identification of dead code (and the later removal of this code) indicates the quality enhancement that can automatically be achieved by performing the migration. The tool reliably detects dead code from live code by utilizing advanced analysis techniques and an extensive rule base tuned for Visual Basic. The dead-code analysis supports the most complex code, for instance, object-oriented techniques and late binding.
The Application Analyzer tool is used by the migration engineer for efficiently planning the complete migration project. The tool gives valuable detailed information directly from the source code to be migrated to enable planning in a risk-conscious fashion.
The tool scans the graphical-user interface and optionally the business logic of the Visual Basic application, detects and reports the exact location of the unsupported components in the source code. These components require special attention by the project team and hence they are important from a planning perspective.
The project architect inspects the listed lines of code and decides what actions are needed and when these actions are to be performed taking into account the technical risk of the solution. The higher the risk, the earlier in the project the problem must be tackled. A solution may for example include finding a matching Java component for a used Visual Basic component, or integration of the migrated system with your organization’s security platform.
The first subsystem is the front-end. The front-end translates the source language into an intermediate representation. The front-end and back-end operates as separate passes, i.e. the front-end calls the back-end as a subroutine, passing it the intermediate representation. This subsystem is also highly extensible enabling different input languages.
The responsibility of the back-end subsystem is to translate the intermediate language used internally within the compiler to equivalent ASP.NET or Java source code. The compiler is shipped with two standard back-end plug-ins, the Swing plug-in and the web-based plug-in supporting both ASP.NET or JSP/JSF. This post-translation is highly extensible. Adding support for new output languages or script languages is as easy as building a plug-in according to the well-defined back-end framework.
The intermediate language engine is the heart of the compiler with unique features such as dead code removal and unique code optimisations. The detection of dead code is recursive (deep detection) i.e. functions called in functions, nested Type's and Enum's and so forth. The compiler detects and removes the following types of dead code:
- Native variables, constants, enums and types
- Procedures, functions and properties
- Dead classes, semi dead classes, dead modules, dead interfaces and semi dead interfaces
- Dead Win32 API functions, i.e. functions that are declared but never called within the application
It can be as much as 10-20% of dead code of a project's size, and increase the EXE, DLL or OCX file size by 100s of kilobytes. This means excessive memory use and slower execution. Dead code also means more source code to read and maintain to your support staff. It leads to higher costs, especially during maintenance. If the code is in there, programmers must spend time understanding it.
Listed below are brief descriptions of the compiler’s general features:
- Direct translation (one-2-one mapping) between Visual Basic and C# or Java
- Translates DLL's, Active-X components (OCX's) and standalone projects (EXE's) including the following type of files: VBG, VBP, FRM, CLS, BAS, CTL, FRX and CTX
- Translates complex projects (Visual Basic Group) including unlimited numbers of OCX's, DLL's and so forth
- Converts ADO and DAO database access into .NET comaptible database access or Java database access using the JDBC API
- Supports many external components, such as Scripting Run Time scrrun.DLL and Winsock.OCX
- Supports a major part of the more advanced Windows Controls, such as ListView and TreeView
- Built-in automatic type casting control and conversion to the native .NET or Java data types
- Built-in source code analyzer for better readability, easier further development and maintenance
- Automatically parses and converts the picture resources, i.e. all FRX and CTX binary files to compatible Java format
- Translates absolute-positioned graphical-used interface to either a relative-positioned web-based user interfaces with easy-to-change cascading style sheets or to a absolute-positioned web-based user interface
- Translates native Visual Basic controls to native ASP.NET server-side controls or to equivalent Java Server Faces controls
- Translates each Visual Basic form and its data to an equivalent ASPX-page with a corresponding code-behind class or to a JSP/JSF page with a corresponding to Java form bean
