The Porting Process
Phase 2. Preparation
This phase involves your development team, with our guidance, in completing the tasks identified during the Detailed Analysis in order to prepare your Gupta / Centura application for translation. The aim of this work is to arrive at source code which will deliver the optimum translated code in .NET. There will be a number of simple tasks to complete – qualifying references, correcting data types where necessary etc. – but one of the key tasks for this phase is partitioning the application to deliver the Visual Studio projects you want to see in the ported application.
Gupta/Unify Team Developer applications are usually monolithic programs in that while the source code is organised in several files, the finished product is one executable containing everything from the source code libraries.
In the Preparation phase the original source code is partitioned - i.e. separated - into logical libraries. This sounds more complicated than it really is because the source project is not modified at all and code inside the original libraries is not moved. It actually means that a parallel set of SAL outlines are created, grouping libraries at a higher level and creating a modularised view of the system. This may be a simple big common library or several layered libraries.
The dependencies report generated during the Assessment phase and the knowledge of your developers is used to group the shared libraries into complete TD files that correspond exactly to one .NET project each. The partitioning solution is your decision and your developers will need to prepare the partitioned code in the appropriate structure prior to translation.
The following simple diagram illustrates this process.
The diagram above is obviously a simplification. In reality, Gupta SAL libraries include other libraries that may, in turn, be included by other libraries. There may be circular dependencies and broken references, as well as duplicated symbols. No matter how complex your system is, however, this technique has been proven to work well. Whether from one single common assembly or several interdependent modules, it has already been tried and tested successfully in real situations.
One of the many advantages of this technique is that the intermediate SAL files can be fully tested and are guaranteed not to alter the original application because they do not contain any code. Additionally, if the original files change during the project, all the intermediate SAL files are automatically updated since the original libraries are simply linked.
The outcome of this phase is a well defined set of SAL files - it could be just one or two, or could be many - that can be independently compiled and tested ready to be fed into the translation tool in the next phase.
