For example, the apparently natural choice of focus for the UML modeling itself would seem to be Enterprise Architect (EA) because of its strong presence in OpenEdge sites now using UML. But, EA has no Action Language and its MDA translation capabilities do not appear to have been robustly tested in similar scope endeavors, although it is believed that Progress Professional Services has done some work which should be considered. Also, while EA has an Eclipse interface, it is not an Eclipse hosted tool, which limits the degree of integration with OpenEdge Architect (OEA). This suggests that an Eclipse-based tool may be worth considering since good integration may trump established market share, particularly considering that the number of existing EA users in the OpenEdge world is apparently not particularly large.
Another interesting question is whether one tries to build on the MDA capabilities in an existing UML tool or considers technology specifically directed at Model-to-Code translation. I’m not sure that any UML tool has an Action Language standard, which implies a rather large investment in new technology development up front. Whereas, if one were to use an existing translation engine one might be able to shortcut that development considerably. In addition to accelerated development, use of a developed tool might substantially enhance the quality and power of the result through such features as tools for model checking and for actual execution of models, a sort of very high level debugger.
In particular, it may be possible to further accelerate development by using one of the packages in the selected translation tools for another language such as Java. While there are clearly going to be places where the ABL implementation will differ substantially from the Java implementation and even the packaging will change, the existing implementation will provide a map on to the model elements which need consideration and guidance for how that mapping turns into language elements in a known language. In many cases, the change is likely to be more in the text produced than in the mapping.
Model-to-Code, Model-to-Model, and Code-to-Model
The primary focus for achieving higher levels of productivity in ABL is Model-to-Code. But, one has to recognize that, as such, it is primarily of use for new development, i.e., contexts in which it is possible to start with use cases and requirements and work toward code which will implement those use cases and requirements. In this process, there are some obvious opportunities for Model-to-Model transformations as well, such as converting an evolved domain model diagram into a class diagram. However, one also has to recognize that there is a great deal of ABL code already in the world and that most of that is not even object-oriented and thus has a somewhat imperfect relationship to even the most concrete aspects of UML.
There are essentially two different routes one could take in trying to deal with existing code and a migration toward a Model-to-Code environment. One route is to approach the problem as a modernization effort, i.e., one in which one will attempt to create a model from the existing code, modify that model to make it suitable for modern development, and then generate code from that model to create the new application. This approach will produce the best ultimate code and the best environment for on-going development, but it is also labor intensive and thus expensive.