Skip to main content

A Path to Model-To-Code Translation in ABL

Printer-friendly version
The normal way of providing less than complete translation is to provide reverse engineering. I.e., one generates code, modifies that code manually in an editor, and then reads the modified code, detects any changes, and captures the added code as text associated with the methods, new properties, etc. in the model. Then, on the next generation, this text is included in the generated code, thus recreating the code as previously modified. This approach presents several problems, including:

  1. Synchronization of model and code is dependent on the user following a well-specified workflow. Failure to check in modified code or working on the model without generating new code will lead to the code and the model falling out of sync. If this persists and the versions diverge, it can be difficult to re-synchronize the two.
  2. The workflow requires moving back and forth between contexts - working on the model in the UML editor, generating code, moving to Architect to make modification, returning to the editor to reverse engineer the code, etc.
  3. Code written outside the model is not coordinated with the model. Thus, it can easily contain material which should have been expressed in the model itself or which is at variance with the structure of the model. Since the code is treated merely as text, there is no way to resolve such discrepancies or even to detect them systematically.
  4. Manually written code is likely to follow the implementation model of the developer and thus including this code will embed that implementation in a model which one would prefer to remain implementation independent. This reduces the flexibility of future evolution of the model and translation.
  5. If the capabilities of the tool increase in the future or the user desires to make greater use of the tool’s capabilities, there is no obvious way in which to evolve the existing model with its embedded code to a new model in which some aspect of what is now in the code is moved to a model element.

Together, these make a strong argument against anything less than a complete solution and consistent 100% Model-To-Code operation, but nevertheless, we have the issue of both potentially wanting to deliver a partial solution and having some users who will prefer a partial solution.

Action Language
When the concept of 100% Model-to-Code translation is introduced to those not familiar with it, the reaction is often skepticism that 100% code generation for any meaningful application from “only pictures” is possible. One element which helps make this capability more understandable, but which is not well known, is Action Language. Thus, before exploring the completeness issue further, it is worth while reviewing what one does to achieve a complete solution beyond “drawing pictures”, i.e., beyond the graphical elements of UML. This question also raises some interesting issues about how code is included in the model.

The Object Management Group2 (OMG), which defines the standard for UML, has defined a standard syntax for an Action Language. The purpose of Action Language is to supplement the relations and actions indicated by the more familiar UML diagrams with an implementation-independent language for use in describing algorithms, i.e., any procedural sequence of operations which is necessary to the correct functioning of the target software. There is as yet no OMG standard Action Language, only a specification for the syntax. Each vendor of translation tools has their own Action Language3.

APathToModelToCodeTranslationInABL.pdf103.64 KB