Most ABL applications have little or no documentation. They rely on “old hands” knowing the code to understand how the application works and where a change must be made. Without such an “old hand”, there is a lot of time wasted reading code to discover what is currently there and a high risk of mistake in making changes.

Model-Based Development for ABL has enormous potential for reducing the time and cost of original development while increasing quality and providing really dramatic improvements in responsiveness to changed requirements. This presentation describes the process of Model-Based Development illustrating with examples from a worked case in which ABL code is generated from the model presented.

With the announcement of Progress Pacific1 in the wake Progress Software’s acquisition of Rollbase, it is natural for those in the OpenEdge world to wonder what the long term rôle is for ABL in this evolved product. Of course, most people coming from an OpenEdge background know little yet about what Rollbase is and how it changes the overall Progress offering. Moreover, it is understandable that many OpenEdgers are skeptical about how much Rollbase adds since OpenEdge’s own tools for web and mobile solutions are substantial. Currently, Progress marketing is strongly emphasizing the new tool and packaging and it is easy for someone in the OpenEdge world to perceive this as a de-emphasis of OpenEdge and ABL.

• 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.

Many ABL systems have their origins many years ago. Most have received many layers of modification, typically resulting in complex and poorly structured systems. Modifying or extending such systems can often be extremely difficult. Good analysis is needed to avoid unintended collateral damage from changes and to decide where to make changes in the first place. Good analysis is also the first step in transformation, since one must know what is there before deciding how to replace it.

This presentation was given to the Russian Progress Users Group (RuPUG) on 24 September 2012. A revised version was given to PUG Challenge Americas on 10 June 2013

If anyone has suggestions for additions, please contact me and I will consider updating it with more material or making some kind of supplement. Similarly, if anyone is interested in my putting together a complementary talk on worst practices, what not to do, please let me know.

Presented at Revolution 2011 - 19-22 September 2011.

Although there are some possible parallels, best practice 3GL object-oriented programming (OOP) is very different in structure from traditional ABL programming. This presentation will review a number of principles of best practice
OOP and explore how these principles can be implemented in the context of ABL. Comparisons will be made of alternate approaches based on performance and principles. The goal of this session will be to assist in making choices about OO implementation alternatives.

Presentation is attached.

This presentation was delivered at PUG Challenge Americas on 6 June 2011.

Model-to-Code translation has the potential to provide the high development productivity and responsiveness required to meet modern business requirements. This paper reviews issues of completeness, action language, realized code, user interfaces, alternate models, and frameworks. This discussion leads to a proposed recommended path for the development of these tools.

Background

Experts tell us that the rate of change in business today has increased dramatically. This creates demands for rapid software development and quick changes to existing software. The compelling story for ABL as a fourth generation language (4GL) has always been productivity. However, the productivity advantage ABL once enjoyed over third generation languages seems not to be as great as it was 20 years ago. I review issues in ABL productivity leading to a proposal for Progress Software to explore Model-to-Code translation techniques as a means of substantially boosting ABL productivity and responsiveness.

Computing Integrity is currently evaluating technology that can be used to transform ABL source code and is looking for companies who have legacy code needing modernization or other improvement so that we can better understand the transformation requirements they face. The transformations we are considering vary from simple operations that improve code quality to substantial transformations required in modernizing an application. While some transformations need some manual aspect, e.g., the need for human design skills, the bulk of the work will be highly automated, ensuring great speed and accuracy. It is anticipated that we will achieve as much as 5 to 1 improvements in the cost to implement any given transformation relative to current methods. Please let us know your transformation needs so that we can insure that our tools address all requirements.