Skip to main content

ABL in a Pacific World

Printer-friendly version
If not template generation, then what?

Is there an alternative? I would like to suggest the Model-Based Development (MBD) provides a much better alternative. In MBD one creates a UML model of the application which is “computationally independent”. This means that the model is not only independent of the specific implementation, but it is independent of the platform and any other computational assumptions. The model is going to be the same regardless of whether one is creating Java to run on J2EE or ABL with an OERA structure.

That this is possible may seem surprising to some, but it is standard practice in some problem domains. In fact, only a tiny part of UML is required to completely specify the application:

  • The Component Diagram to specify the structure and interrelationships of the parts,
  • The Class Diagram to specify the details of each class,
  • The State Chart to specify dynamic behavior, and
  • Abstract Action Language (AAL) to specify algorithms and similar logic.8

Other diagrams may be useful in deriving and documenting requirements or to provide a different view, but only these diagrams are required to fully specify the system. This model then translated into the desired implementation language. The translator I am using creates all language and architectural structures during the translation process.

The implication of this approach is that one gains significant productivity during initial development, but more importantly, dramatically increased productivity when revising requirements in much the same way that these gains have recently been reported for Corticon. If one is happy with the current implementation design, all one has to do to implement a change is to make simple changes in a visual UML tool and the launch the translator to produce new code. If one changes one’s mind about the implementation design, then one has to change the translation templates, but the work required is a tiny fraction of the work required to manually retrofit the application code. With MBD, one makes any desired modification to the translation templates, then runs the translator and has new code end to end. Even major shifts in architecture can be accomplished without altering the model9.

Summary

I urge Progress Software to explore the potential for Model-Based Development in ABL since:

  • MBD for ABL provides the same kind of productivity advances that Rollbase, Corticon, and OE BPM provide;
  • MBD for ABL provides the responsiveness to changed requirements that other model-based system like Corticon and OE BPM achieve;
  • MBD for ABL produces a coherent message since both Corticon and OE BPM are touted for being model-based10; and
  • Providing MBD for ABL will make ABL “sexier”.

Not only will MBD for ABL improve OpenEdge and Pacific for developing new applications, but MBD can provide reduced and improved transformation of legacy ABL applications though further development of code-to-model tools11.

I will be speaking on MBD and showing some models and their transformation to ABL at the PUG Challenge EMEA in November 2013.

  • 1. Pacific is the name Progress has given to the entire Platform as a Service offering including Rollbase, OpenEdge, Corticon, OE BPM, and Data Direct Cloud. Those who have not been to Exchange or been otherwise exposed to the full message on Pacific may have the misimpression that Pacific is a Progress rebranding of Rollbase.
  • 2. PaaS means providing both the cloud infrastructure and the development platform to create applications on that infrastructure. Thus, it is midway between IaaS (Infrastructure as a Service) offerings like those from Amazon and SaaS (Software as a Service) offering such as a specific ERP application sold on a subscription model.
  • 3. CRUD = Create, Read, Update, and Delete.
  • 4. BRM = Business Rules Management, i.e., Corticon.
  • 5. BPM = Business Process Management, i.e., OE BPM derived from the former Savvion product.
  • 6. Productivity on a pair of new applications over a two month period averaged 1000 lines of ABL code ready for integration testing per programmer per hour.
  • 7. A lack of regenerability and architectural dependence concerns me to some extent about Rollbase. While we don’t yet know what the likely evolution will be of web applications, it seems likely that they will evolve in significant ways and thus it seems likely to require significant redevelopment.
  • 8. See http://www.cintegrity.com/content/Model-Based-Development-Day-Life for a short presentation on the nature of Model-Based Development.
  • 9. I should note that it is common to “color” parts of the model. This “coloring” is not a part of the model, per se, but is provided to give hints to the translator about which templates to use for particular parts or which “flavor” of implementation to use. A major change in architecture may thus require a certain amount of recoloring the model to get optimum results, but the model itself will remain unchanged. Any such requirement is still a tiny effort compared to migrating the application by other means.
  • 10. Also see two older white papers about rapid change and ABL, http://www.cintegrity.com/content/Rapid-Business-Change-and-ABL-Producti..., and specifically on a path for ABL translation, http://www.cintegrity.com/content/Path-Model-Code-Translation-ABL
  • 11. See http://www.oehive.org/ABL2UML for tools that provide the foundation for this approach.
AttachmentSize
ABLinaPacificWorld.pdf68.95 KB