Skip to main content

A Path to Model-To-Code Translation in ABL

Printer-friendly version
Practical Issues of Completeness
Returning to the question of completeness of the initial release of Model-to-Code functionality in ABL, it appears that there are somewhat contradictory strategies. One strategy aims at an initial release which will provide less than 100% Model-to-Code translation and which uses reverse engineering to incorporate manually coded implementations into the model. This approach may be more comfortable to some developers, especially as a first step, but has a number of hazards in the quality of the model and no clear path to evolving a more complete translation. This approach seems to point to the use of ABL as an “Action Language”, since the reverse-engineered code would be filling the rôle of the Action Language, albeit in an implementation dependent way.

The other strategy aims at an initial release which provides 100% Model-to-Code translation. This approach seems to point to the use of an formal Action Language, not ABL, possibly an existing language in order to articulate with an existing translation engine. User acceptance would require more persuasion with this approach, but the tangible benefits are also substantially higher, providing a more compelling story.

While it may seem intuitive that the incomplete translation would require less work than complete translation, this may not be the case since the complete translation approach may take advantage of existing technology while the incomplete translation implies building all tools from scratch. It might seem like some of Phil Magnay’s work10 on ABL with Enterprise Architect would provide a foundation for a solution involving reverse engineering, but issues about that work may mean that it doesn’t provide a foundation which would meaningfully speed development.

Therefore, I suggest there should be a two pronged attack on development. One branch will assume that a complete solution is the preferred solution and will investigate existing Action Languages and translation tools to evaluate whether they would form a sound and acceptable basis for an implementation along with a projection of the time and costs involved in such an implementation. The other branch will survey potential users about acceptability and preferences relative to user preparedness to use a 100% solution and what factors would influence their attitudes and acceptance. This branch will also explore potential avenues to reverse engineering as well as any existing efforts at Model-to-Code translation for ABL.

Articulation with “Realized Code”
Systems utilizing Model-to-Code translation for some of the overall system often also include pre-existing code, other software packages, purchased components, etc. In these cases, it is not possible to model that part of the system, often because one does not have source code. Such pre-existing code external to the modeled code is called “realized code”, i.e., code that has already been realized into working form by some process other than that being used to produce the modeled code.

While the historical distinction of ABL was built on the idea that it was a 4GL in which one could write 100%11 of an application, as the computing world changes, this may no longer be desirable. One is not speaking here of a return to 4GLs in which a portion of the application was written in C, since that too is code that might be modeled, but rather to the use of applications and tools which are given responsibility for some part of the application.

APathToModelToCodeTranslationInABL.pdf103.64 KB