Skip to main content

A Path to Model-To-Code Translation in ABL

Printer-friendly version
Frameworks
Modern development often involves development relative to a framework responsible for providing basic services. This framework may be purchased, in which case it is treated as realized code. But, in the current construct any framework would be provided with the tool and would be written in ABL. While it is possible to create such a framework by conventional coding mechanisms, given a high quality Model-to-Code translation mechanism, there is no reason not to create the framework using the same facility. Indeed, constructing the components of such a framework would provide a good test bed for the translation engine and rules. Moreover, the model used to produce the framework would provide an excellent example to potential users of the tool. In addition, using this approach would allow the framework to evolve gracefully with changes in technology.

The big danger here is similar to that discussed previously, i.e., customization of the framework by users at the same time that the core framework is evolving. Again, continuous publication can mitigate this problem. Also, development of a community of users has the potential to yield valuable contributions as users enhance the capabilities as well as create their own special versions that will not have general applicability.

The key to allowing graceful evolution will be to provide clear separation of concerns and a well-defined interface to each package in the framework. This is good OO design anyway, but will be particularly important on common components which may be subject to customization requirements. By providing a very clean isolation of the responsibility in each package and a simple, but complete interface, one separates the use from the implementation so that users can be free to use alternate components tailored to their specific needs and yet preserve the same interface and thus not be subject to version disruption.

One should note an established principle of good Object-Oriented design is that subsystems should be highly coherent, dedicated to a single purpose, and loosely coupled with each other. One is thus able to treat any subsystem as a “black box” when working in any other subsystem and such subsystems can be separately modeled, and separately created. One sees that principle here for both the visible part of the user interface and the framework(s), but in practice one would also see it in other subsystems like the data access subsystem. E.g., ideally, the data access subsystem would be the only one aware of the existence of the database and its table and field artifacts.

Source of Technology
There are a number of different options for the source of this technology. Some of it will be new and unique to this new tool and so will have to be developed. But, there are options for open source, license, and resale agreements for contributing parts of the technology which can substantially alter both the amount of work required to produce a working product and the quality and the power of the result.

AttachmentSize
APathToModelToCodeTranslationInABL.pdf103.64 KB