Skip to main content

A Path to Model-To-Code Translation in ABL

Printer-friendly version
Creating a model from code is as difficult as it is, not only because most of the code is not OO and is often not well structured, but because there is an inherent loss of information when one moves from abstract to concrete. The concrete code which comes from a Model-to-Code translation doesn’t include the abstract information about use cases, requirements, and intent which are in the model. Neither does legacy code and such information may not even have been explicitly expressed either when the code was originally written or at any time since.

There have been efforts such as my ABL2UML13 and the derivative work ABLaUML14 which will build UML models from existing ABL code, regardless of programming model or style. These models are quite extensive and are very powerful analytic tools, but do not currently include the actual ABL code from the source, although this is a planned extension. This is, however, a component model, not a class model, and certainly does not have any of the abstract layers one associates with a full Model-to-Code project. It is likely, however, that this is a valuable analytic step even if one cannot directly create an analysis model from this import. Moreover, it is a valuable analysis model even without utilizing any Model-to-Code features.

Thus, it seems valuable to consider how this work can be extended, both to include more information in the model for analysis and to create Model-to-Model translations which can assist in building the kind of analysis model one would like for Model-to-Code work. While considerable human effort is certain to remain, it seems likely that tools can be created which will facilitate the process and reduce the work. For example, the ABL2UML component model includes links between each program and subprogram component and any data elements referred to in that component including the fields involved, read/write access, where clauses, etc. This means that one can start with any given table and quickly identify any code component which uses that table, the mode in which it is used, and thus also any business logic which might be applied to that table. Since tables are often considered as possible first pass candidates for classes in the class model, this provides a semi-automated way to identify all the properties and behavior associated with that class. Since the links are quite fine grained, if one decides to analyze a given table into a super class with multiple subclasses, a common refactoring, one could rapidly identify which components related to which properties of which subclass. There are undoubtedly other ways in which either reports or actual Model-to-Model translations could assist in building a base model from which to create Model-to-Code translations.

The other approach for dealing with existing code would be to provide Model-to-Code translations for the component model itself. This would allow someone who was not interested in making the transition to full Model-to-Code (or unwilling to make the investment) to still analyze the component model, make changes, and output revised code. Some research is needed to see how much interest there would be in such a capability. Given that we add code to the model, it is probably not difficult and would facilitate some kinds of structural refactoring, but it may be that the interest is too low to justify the effort, even though I don’t believe the task is particularly difficult.

AttachmentSize
APathToModelToCodeTranslationInABL.pdf103.64 KB