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.

Due to issues with spam, creating user accounts has been disabled. Please send e-mail to thomas at cintegrity dot com with a request for an account if you would like to comment on pages.

Layers, Subsystems, and Separation of Concerns, Oh My!

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.

How Can I Fix That? Applied Use of ABL2DB on Real World Problems

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.

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.

Syndicate content