Skip to main content

Welcome to Computing Integrity

Welcome to Computing Integrity!

Consulting and Tools for Architectural Modernization and Transformation

Computing Integrity is ready to assist with consulting, tools, mentoring, and development skills for any application modernization from full transformation to small, incremental projects.

Register and Login to leave comments.

What Code Updates That Field and Similar Problems?: Databasing ABL Code and Data Relationships for Analysis

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.

Understanding Legacy Code Through Modeling

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: A Practical Introduction

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.

ABL in a Pacific World

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.

Analysis Problems in ABL and How To Solve Them

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.

ABL Best Practice Programming

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.

Practical Considerations in OOABL Programming

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.

Thinking OO for the Legacy ABL Programmer

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

A Path to Model-To-Code Translation in ABL

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

Rapid Business Change and ABL Productivity

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.

Syndicate content