Skip to main content

A Path to Model-To-Code Translation in ABL

Printer-friendly version
Alternate Models
One notable characteristic of the ABL development community is lack of a dominant programming model. ADM has probably been the model with the widest adoption, albeit in multiple versions, none of which are really OERA compliant or Object-Oriented (OO) as one would expect to get from a tool of this sort. Various models have been offered for OERA applications, although most have limited publicly available documentation. How then is one going to accommodate this diversity of opinion in a Model-to-Code translation tool? Or should one?

One can argue, meaningfully, that many of the models now in use are not good models in a number of respects. Moreover, very few traditional models are based on OO12. One might wonder if providing a single, well considered model which implemented OERA principles and illustrated adherence to good OO principles would not be sufficient. While defensible, it also could be true that support for alternate models would increase acceptance. One important question one might ask is whether it is possible to support multiple models without undue burden.

This question really has two components – one about whether the transformation is open for the user to customize and the other about whether more than one model is supported out of the box. There is some need to support alternate models in any Model-to-Code translation simply because different approaches are often needed in different parts of an application for performance or compatibility issues. This mechanism is often called “colorization” or model markup. It means that properties are attached to the model which are not a part of its functional structure, but which tell the translation engine to do one thing versus another during the translation process. Naturally, providing such options add to the complexity of the translation templates. Thus, it would be possible to provide alternate models via markup, but it would add substantially to the work required to create the model.

The question of openness is also difficult, as illustrated by the history of ADM frameworks. Those who worked entirely with the ADM framework as shipped were often able to move to a later version without a great deal of difficulty. Those who customized the framework, however, (especially common with earlier versions) often had considerable difficulty in moving to new versions. While they could run the application with the old framework and the new version of Progress, they could not take advantage of the features of the new version of the framework running that way. If people customize the translation templates, we are likely to see similar issues here. However, at the same time, the ability to customize can often be the difference between acceptable and not.

It has been suggested that most of the difficulty experienced with user customization of framework components comes because a new framework is typically available only yearly. Consequently, a user feels a need to make customizations because he or she can’t wait a year to see if desired functionality will be added. Meanwhile, the team responsible for maintaining the framework is modifying the framework according to some master plan which is unknown to the users. The result is divergent development over a substantial period and the consequent difficulty of resolving the two versions.

One solution to this dilemma is continuous availability of new versions, i.e., to make new versions available as rapidly as they are created, making well documented changes in individual components rather than sweeping restructuring whenever possible. This might be done through an on-line community which also provided a feedback mechanism by which individuals could contribute candidate changes for possible inclusion and where they could make requests for options in the overall framework. One should also have a visible planned direction of development so that users can anticipate future directions of development. Such a community would also help to publicize the tool.

AttachmentSize
APathToModelToCodeTranslationInABL.pdf103.64 KB