The familiar OpenEdge Reference Architecture diagram has made most of us aware of the idea of separating layers of an application to improve maintainability. This layer separation is a specific example of a general principle of good Object-Oriented design called Separation of Concerns. In this presentation we will explore this principle and its application to interfacing subsystems of an application with specific code examples illustrating Parameter Objects, JSON, Dispatching, Dependency Injecting and Messaging.

Legacy applications are often faced with difficult problems of maintenance and enhancement. This difficulty arises because of the lack of meaningful documentation and bad coding practices in the legacy code. When one wants to make enhancements or changes, it can be difficult to identify all affected areas and the full impact of the change. When trying to correct bad legacy coding, it can be difficult to understand the code, making it hard to design good replacement code.

The ABL compiler provides some valuable tools for analyzing individual compile units, but this information can become far more valuable if systematically gathered into a database and supplemented with other information and analysis tools. A presentation will be made of a new open source toolset, ABL2DB which provides the tools needed to build such a database including supplemental tools for additional information and analysis.

See ABL2DB - Databasing ABL information for Analysis for the code and documentation.

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.