You've got business applications written in a language, which is no longer supported. Or you want to be able to take advantage of other hardware platforms. Or you are having trouble finding enough programmers to maintain your application because of the language it was written in. Whatever the reason, you're contemplating moving your application from one language to another. What does a project like this entail?
I can automate one step of the process--the actual translation of the code from one language to the other. But the actual rules for the translator to follow are different for every project. Coming up with those rules requires experts in both languages, plus someone who knows how the application is supposed to work. I rely on these experts to show me examples of code from the original system and how they would translate them to the target language. From these examples I write the translator.
I can't automate the design work, the formulation of the translation strategy. The other major part of the effort is the coding of the support libraries. For instance the AREV translator relied on VB libraries to do the string processing with the same semantics as AREV.
The first step is to analyze the original source and the target language. How different are they? What does the original language do that is very different from the target language? Remember that you're not out to perfectly translate every feature from the original language, only the ones that you use. In my AREV translator for Harry and David I didn't do anything with the AREV database calls. Only one small program used them so it was quicker to translate that by hand. Focus on the difficult parts of the application. Look at the hairiest code you have. Can you think of some rules you could use to translate it? If so then I can probably write a translator for it. If not then you probably need to scrap the code anyway.
In the second phase I write the parser, tree grammar and code emitter. The rest of the team works on the support libraries and translation examples.
After that I write the code analyzers. I can then answer "which parts of the language are really used?" I can analyze data flow and control flow. I can detect and eliminate dead code.
Then I can start writing the translation phases. Expressions first, then control flow, then language specific things. Up until now you haven't seen any results, but the bulk of the work is done.
Once the basic translator is working the real fun begins! Compiling the translated code will detect some translation errors. Those are quickly fixed. The translated code can begin to be tested. This refinement phase progresses quickly. Once we were at that stage with the AREV translator I could usually code every new refinement within 24 hours. At the same time the rest of the team is testing and finishing the support libraries and making sure the translated code behaves just like the original. I would highly recommend thorough unit testing at the stage, if possible running the same tests on both systems to make sure they act identically.
Sample times for the AREV to VB project:
| Time | Translator work | Support work |
| Oct | Analysis, feasibility | translation strategy |
| Nov-Jan | Parser | Support libraries |
| Feb | Translator | Support libraries |
| March | Translator working, refinement starts | Support libraries, compilation |
| April | Refinement done, translator finished | Support libraries, testing |
| May-Sept | One translator bug fixed (ten hours) | Testing and debugging |
The team was myself on the translator side, three AREV experts and three VB experts to program the support libraries, and a team of six testers/business experts to exercise this complex GUI order entry system.
Unfortunately I don't own the original AREV translator, but if I were to do another AREV project I could write the parser and translator framework considerably faster. After that I could reuse the code for other AREV projects, and the only part I would need to would be the project specific refinements, recognizing code idioms and translating them appropriately.
The first AREV project suffered because we had no one who was an expert in both AREV and VB, so each side was continually learning about the other language. The massive amount of testing also entailed working out platform migration issues resulting from moving from OS/2 to NT, switching our network from token ring to ethernet, learning the idiosyncrasies of the new operating system, and a journey through "DLL Hell."
Most of the effort for the support libraries went into emulating the AREV screen handling and making a screen driven application behave in an event driven environment. There were also string manipulation, data conversion and special comparison routines to make comparisons work as they would have in AREV.
You must consider the alternatives to translation too. Can you buy an off-the-shelf system and migrate your data? What would it cost to rewrite the system from scratch? If you consider rewriting, how much of the business rules are documented? If you don't go for a full translator I can still be a big help by writing the parser and analysis tools so you can visualize data flow and control flow and extract your business rules from the code.
Of course the main advantage of a translator over doing it by hand is consistency. Translation is a very exploratory process and as it progresses you will find that you need to radically change a translation rule because of a false assumption. If you're doing it by hand that means basically starting over. If you have a translator program, you just run it again on all the code at once. For the AREV project I would translate all the code every night. Major changes were safe to try because I could always revert to any previous version of the translator as needed.
Look at your code. What are the challenges going to be? How much effort will need to go into the support libraries? How can you test the translated code to know the translation works properly? Do you still have any of the original authors around? Do you have the experts who can design the translation rules? Answer these questions and I think you'll have a pretty good picture of the effort needed to do the translation.