Skip to main content

A Path to Model-To-Code Translation in ABL

Printer-friendly version
One idea, previously advanced by John Green and I4, is that one could construct an Action Language which was essentially a subset of ABL. This would preserve the high level character and would greatly simplify both Model-to-Code and reverse engineering. This approach might also provide a more natural transition for existing ABL developers. This might be consistent with reverse engineering modified ABL code back into the model as discussed above, but is also subject to the cautions cited above.

The intention of UML is that models remain independent of implementation specifics as much as possible. Use of a subset of ABL as an Action Language would violate this principle both in that some ABL syntax would not readily be translatable into any other language and that there would be a strong temptation on the part of experienced ABL programmers to “solve” parts of the problem in the Action Language segments which properly should be solved elsewhere in the model.

One of the things which may surprise an ABL programmer is the apparent “primitiveness” of Action Languages (See, for example, Platform Independent Action Language5, BridgePoint6, or SMALL7). The secret to understanding its apparently simple character when compared to ABL lies in two factors. One factor is the desire for the Action Language to be highly abstract from the implementation, i.e., for the syntax of the Action Language to be independent of the syntax of the target language or anything else about the target platform. The other factor lies in understanding the simple job which is required of an Action Language. In most cases, an Action Language fragment is nothing more than the specification of what happens in a particular method and thus is inherently quite simple.

The best Action Language to use for ABL translation will need further exploration, but it seems likely that the best choice will be and existing formal Action Language like like SMALL, BridgePoint, or PAL8 rather than an ABL subset for three significant reasons:

  1. Formal Action Languages are language neutral;
  2. Formal Action Languages are implementation independent; and
  3. Use of an existing Action Language may make it possible to use existing translation tools.

To be sure, the typical user may prefer a subset of ABL as something which was already familiar, but the entire language of a true Action Language can be documented on a single side of a single sheet of paper, so there is not a huge investment in learning required. Moreover, working in an Action Language will reduce the temptation to simply “start writing code” resulting in a model which is tied to a specific implementation model and in which important information is represented in the AL instead of in the model structure.

Once introduced to the concept of Action Language, a skeptical person may think one is going to have just as much code in Action Language as one would have written without the UML. One might then wonder whether anything is really being gained. This reaction may be likely in ABL programmers who are certain that the seemingly “primitive” nature of existing Action Languages will result in even more Action Language code than there would have been ABL. In fact, a great deal of the application code comes from the model itself and the Action Language is only required for limited purposes. One very complex device driver of which I am aware was about 750,000 lines of code altogether, but had only about 10,000 lines of Action Language9.

APathToModelToCodeTranslationInABL.pdf103.64 KB