Skip to main content

A Path to Model-To-Code Translation in ABL

Printer-friendly version
One of the obvious current examples of including non-ABL components in an overall solution is externalizing the workflow of an application into a product such as Savvion BPM. Without Savvion, one would model the workflow as part of the application. With Savvion, one wants Savvion to be in charge of workflow. One might think this would lead to difficult orchestration of two separate solutions, but, in fact, there is a very natural way in which Savvion and ABL code can be integrated. Any place in the application where one wants to invoke Savvion one is going to send a message from the ABL. Any place that one wants to have Savvion invoke the application one will need to have a facility in the ABL to receive a message. This is no different really than sending or receiving such messages from an ABL component except that in this case the recipient or source is a black box of external code.

If there is an articulation issue with Savvion, it is that one wants to model processes in the UML to provide a complete model, but one also needs to model these processes in Savvion to generate the code in the Savvion system. There is some potential for importing and exporting BPMN models with Savvion that will warrant further exploration. With good integration, actual import and export may not be required. One might consider similar integration with Apama.

User Interfaces (UI)
User interfaces present a special problem for Model-To-Code translation because they involve appearance as well as knowledge and behavior. Many types of user interface also include significant amounts of realized code, e.g., the .NET controls in an ABL GUI for .NET interface. With a legacy architecture having UI, business logic, and data access all intertwined, it could be difficult to create models which had the desired UI, especially since one would not have the advantage of visual design tools. However, with modern architectures, there is a strong separation between the purely visual parts of the UI and the part managing logic and state. In some UI technologies, e.g., RIA, significant parts of this subsystem may even be running on the server.

Thus, the solution to handling one or more user interfaces in the context of Model-to-Code translation is to treat the visual part of the UI as realized code similar to the way in which one articulates to Savvion. The UI is a subsystem of realized code created in a separate tool which sends and receives messages to the rest of the application. In some cases, e.g., Java versus .NET OpenClient, one may use the same ABL components from the model and freely substitute the desired UI. In other cases, some alternate ABL components may be required specific to the UI, but these should be limited since most components should be independent of the UI and thus common across all UIs. This clear separation between the visual part of the UI in realized code and the rest of the application in modeled code should emphasize good separation such as is specified by OERA.

AttachmentSize
APathToModelToCodeTranslationInABL.pdf103.64 KB