Skip to main content

Rapid Business Change and ABL Productivity

Printer-friendly version
Model-Driven Architecture and Translation
In recent years this personal quest for productivity has turned toward Model-Driven Architecture (MDA), the name given by the Object Management Group6(OMG) ), which defines the standard for UML, to generating application code from UML models. Some practitioners prefer to speak of “translation”, as in translation of a model to code as being a more intuitive name for the process. While one generally thinks of MDA or translation as producing code from a model, the technology also includes Model-to-Model translation, in particular, creating a more platform-specific form of a model from a more platform-independent form, e.g., creating the model related to a particular UI platform.

There are several ways in which MDA enhances developer productivity. First, obviously, there is a substantial part of any application for which the implementation is entirely predictable from the combination of the functional requirements and the current development model. It is exactly this kind of code generation which SDD was created to exploit. While some up front effort is required to create the translations to produce the current development patterns from the model; after this investment is made, the definition of the model takes a small fraction of the time required to code the function by conventional means. More importantly, perhaps, the existence of a model implies up front analysis which decreases the likelihood of design flaws and increases the fit to requirements … including the clarification of those requirements before any code is produced. Improving fit to requirements reduces wasted time modifying a completed program to fit requirements which were not clear or explicit at the time the program was originally written.

Perhaps more important, however, is the impact on changes. If requirements change, one can quickly change the model and “push the button” to produce a fresh copy of the application. Not only is this extremely rapid, but the resulting code is highly stable and consistent—one of the big benefits I discovered with code from the SDD technology. Because of this stability and predictability, testing requirements are greatly reduced. In effect, one tests the translator initially and then much of the test of a new function is fulfilled by the pre-existing test of the translator because the translator can be relied upon to produce consistent results.

Even more dramatic is the impact when there is a change in the implementation. If one decides on a new feature or bug fix or change in operation, all that needs to be changed are the translation rules. Depending on the change, this can vary from trivial to significant; but even when significant, it is many orders of magnitude less work than having to rewrite every relevant part of the application. Change the translation, “push the button”, and one has a whole new application which incorporates the new feature—typically at a tiny fraction of the effort that would be required to have manually implemented the change in conventional code.

If the change is more substantial, e.g., a new client type or a major change in architecture, then the savings in effort can be even more dramatic. While revisions to the translations take effort, the effort is more on the scale of figuring out what change needs to happen to a few instances of the impacted existing code than it is on the scale of applying that change to every instance of that structure throughout the code. Even something as sweeping as a change in client technology is a process of revising one set of translations that already covers all cases and then applying that set to all instances rather than having to consider each instance directly. Even a change in the target language for the client is a modest effort compared to manually rewriting the client code.

Indeed, one of the very attractive aspects of this technology is that a unified model can readily produce both ABL server code and non-ABL client code, if that is what a particular shop would like. One can readily produce multiple client code sets in different technologies if such is desired.

One should emphasize that this ability to produce new code from a revised model is a major watershed difference from one-time code generators in which code is created originally and then manually maintained going forward. If it is desired to change the implementation in some way, the only advantage one has with one-time generation code is the uniformity of pattern which might help in applying substitution tools. With true regenerability, the model can evolve repeatedly and the code reflects completely the on-going principles of design and implementation.

RapidBusinessChangeAndABLProductivity.pdf73.88 KB