DB2 & IMS

  • The abstraction of business (if, then, and else) logic
  • The decoupling of business rules from the corresponding application processing
  • The externalization of business rules updated and maintained via table changes
  • The creation of temporary in-memory data structures that facilitate and optimize complex algorithms.

Re-engineering for minimal maintenance is often dictated by implementing new business processing as required and if resources are available. The result is a gradual shift from a procedural to a table-driven approach to application development. Because a table-driven design approach contributes to solving business problems, the design principles that lead to procedural information systems development continue to be used. Table-driven design is an extension of traditional procedural design, not a replacement for it.

Easing Application Development

Table-driven design applies to every stage of the application lifecycle. Tables are used to define, design, develop, and enhance the application system. They provide the foundation for a smooth flow through all stages:

  • In the analysis phase, tables provide concise, orderly specifications of the business challenge. The problem here is to restructure existing program code to minimize the impact of anticipated classes of future maintenance.
  • In the design and development phase, tables can be implemented directly from specifications, providing a close link between theory and practice.
  • In the ongoing enhancement and maintenance phases, shared tables allow for single, centralized changes, fast turnaround and high productivity, with minimal risk to existing program code.

Abstraction of Rules

Traditional design has, for largely historical reasons, embedded tables of rules in program logic in various forms, such as IF, THEN, ELSE and other branching constructs or declarations of arrays in working storage. The abstraction of rules to separate control data from process is initially more intuitive than obvious. But it’s straightforward once you understand that it consists of gathering similarly structured rules together and loading them into a table. Rules are associated with data entities or objects that are being processed.

Consider the snippet of business rules in Figure 1. The values ‘01’, ‘02’ and ‘03’ of the logic are abstracted and placed as individual rows in a table. Included in each row are indicators for associated actions. Then, checking the table at execution time determines what actions should be performed for the given taxpayer type. Equivalent table-driven code would be of the form shown in Figure 2.

The restructured code allows for changes in actions performed for a particular taxpayer type simply by updating the table, without modifying the program code itself. This type of logic construct is sometimes called “action-oriented” as opposed to the more traditional “condition-oriented” constructs so often found in procedural code. This simple change in code decouples the controlling logic from the processing actions. When conditions change in the future, table updates control the processing actions. To create new processing actions is simple in the revised table-driven code.

There are many ways of abstracting logic and the goal is always to decouple the condition from the action to create truly flexible, minimal-maintenance applications. It’s beyond the scope of this article to elaborate in detail on the various decoupling techniques of table-driven architectures.

This decoupling has a dramatic effect on the steps in processing a typical change request for a traditional procedural application depicted in Figure 3. Figure 4 lists the steps involved in processing a change request for an idealized table-driven application, where the business analyst has direct update access to business rules in tables.

5 Pages