Skip to main content

A Path to Model-To-Code Translation in ABL

Printer-friendly version
Recommended Approach for PSC
Providing a complete MDA solution is obviously a non-trivial endeavor, so it is important to both pick good goals and to identify useful delivery stages15 in order to insure that meaningfully useful utilities are delivered to developers with each release. Thus, the first phase of this project should be to determine these goals and stages. To this end it is recommended that an evaluation and catalog be made of both the PPS CloudPoint offering and, if possible, the iMo offering to identify what each has accomplished, the shortcomings of each, and the degree to which the tools involved are a sound basis for further work. This review should also include any related products and efforts such as ABL2UML and the publicly released tools by Phillip Magnay.

In addition to reviewing existing ABL-specific tools, a review should be made of possible sources of technology including both UML tools and translation tools. The review of UML tools would clearly include Enterprise Architect for reasons mentioned above as well as its rôle in some of the existing ABL tools. The review should also include UML tools which are built on Eclipse, including any which are compatible with identified translation tools. The survey of translation tools can be limited to those which have the potential for adaptation for use with ABL16.

These reviews will determine what is potentially available to help kickstart or accelerate the effort and what needs to be done from scratch. As discussed above, this should be a two pronged review – one branch exploring 100% Model-to-Code translation as the deliverable for the first release and the other exploring the possibility of partial solutions. This review needs to both include technical possibilities and potential as well as market acceptability and interest.

From this review we will construct a phased delivery schedule and goals along with addressing such issues as packaging. For example, if one were to decide not to use existing translation tools and a partial translation solution were desired or acceptable, one might arrive at a schedule such as:

  • Phase one might be to provide an OEA-based equivalent to ABL2UML including code plus MDA from class diagrams to create object shells and reverse engineering to read code from filled in shells to the model.
  • The second phase might include some model-to-model transformations to build analytic models from the ABL2UML component model, some model-to-model translations for analytical to design models, and extension of the MDA to include Activity and Sequence diagrams in the MDA with some configuration options as to how to treat code in reverse engineering.
  • The third phase might then fill out these transformations and add an Action Language.

Alternatively, if one of the translation engines was sufficiently promising, one might aim for an initial release which was more of a 100% Model-to-Code tool and subsequent releases might be focused on enhancing integration and features. One casual estimate is that basic 100% Model-to-Code translation could be accomplished in as little as 5 person months of effort17. More detailed analysis and prioritization, as well as determining the resources available, will need to occur to determine what is feasible and appropriate in each stage.

I believe that a critical element in the acceptance and perceived utility of this capability will depend on its configurability. While it is certainly true that there are many in the ABL community who could use strong guidance on best practice, e.g., with respect to good OERA architecture, this tool will not be used if a company cannot easily personalize it to suit local needs and tastes. Not only is this essential in the initial release, but subsequent releases must support earlier choices and work, i.e., it is important to avoid a scenario such as we have seen with ADM and ADM2 in which a shop that does significant customization then places themselves in a compromised position for accepting new versions of ABL, often having to go through lengthy test and conversion process to resolve the old version, new version, and customizations. One possible option toward this goal might be to place the transformations themselves in an open source community where they could continuously evolve. PSC could contribute to that effort, but then always use transformations from that community and support all variations in the community. As noted above, this approach might also be used for framework components, both to ease version transitions and to encourage contributions from the user community.

APathToModelToCodeTranslationInABL.pdf103.64 KB