Object-Oriented Design in TPF
by Jeff Robinson

Does your project plan always seem to fall apart as an impending deadline approaches? Do your developers grumble about having to follow an antiquated design method which no one agrees with but are required to do? As a project leader/manager, are you sometimes unclear as to which area a programmer is working on as it relates to the project design? Are your programmers quick to say "Enough of this design stuff, let's just start coding"?

If you've ever encountered any of the above problems, an object-oriented management and design (OOM/OOD) approach may be the answer for you. Now, I'm sure the term "object-oriented" will elicit various reactions from readers not the least which may be the assertion that TPF is NOT an object-oriented environment or language. Nevertheless, techniques from the OO world can definitely be applied to TPF application development. As a former project manager myself, I have successfully used OOD and can attest to the increased productivity and efficiency the correct use these techniques can bring.

What's An Object and How to find one in TPF
In simple, everyday terms, an object is the same thing you learned it to be as a kid: anything that you can see or touch is generally referred to as an object. Thus, if I look around the room I'm in at this moment, I see objects that have names such as chair, desk, book, computer, etc. However, objects can also be perceived (or abstract) items in our existence: day of the week, time of day, value of goods, gross weight, etc.

Since the field of data processing (including TPF) attempts to emulate things which exists in the real-world, it shouldn't be difficult to determine the meaning of an "object" as it relates to application development. In fact, if you can identify a data entity in a computer system, then you have identified a potential object. For instance, a payroll application might have its data grouped into areas identifying employee records, department files, salary grade records, and bank deposit transactions. From an object-oriented perspective, all of these could be re-designed to serve as objects.

Object-oriented design begins with the identification of real-world and abstract objects that are then represented by programming-language objects. The process concludes with identifying the operations on those objects and then building a system from those objects and their operations. The goal of OOD is to take a problem from a higher level of discussion to the lower level of development which involves the data entities (objects) and modules in your application.

To identify objects in your TPF shop, think of the major data components or areas that comprise your system. If you work with customers, guests, or passengers, your system may use either a Customer Name Record, Guest Name Record, or Passenger Name Record. If your system keeps an inventory of goods and services it sells, then there is likely to be an inventory record that is kept up-to-date in your system. All of the foregoing examples can qualify as "objects" for our discussion here. Finally, don't forget the most obvious object of all that every TPF shop uses: the ECB or Entry Control Block. From the OO perspective, the ECB is just one big conglomerate object consisting of various information including the user's keyboard entry to be processed.

Bringing OOD to TPF
Using the approach I'm about to suggest, you can easily use some of the techniques of OOD to gain better control of your projects, manage tasks according to "object-function" areas, and increase the productivity of your developers. In past projects, I've had the unique pleasure of applying an OOD approach and realized both immediate and long-term benefits. As I outline this approach in the following steps, I'll also point out the benefits that each step will bring. After you finish the design and are ready to begin the coding tasks, both you and your programmers will see all the pieces fall in place like a jigsaw puzzle. (Before you begin the steps below, the problem identification and analysis phase should have been completed. At this point, the goals of the project should be clearly understood by all involved. When I did project management, I generally had a pre-design session in which I briefed the team on the results of the analysis phase and gave them a chance to ask questions and discuss aspects of the analysis phase.)

STEP 1: IDENTIFY YOUR OBJECTS
As discussed previously, objects are the data entities that will be used in your application. This includes traditional TPF files, TPFDF records, DB2 tables and unions, etc. You and your team should have a general idea of all the data areas that will be affected and to what extent. If the object is a new one, then this is the time to design it as well. This step also gives you a chance to learn more about the "objects" in question and to ask for expert advice in case its an unknown data entity. The benefit of this step should be obvious: when you're done you'll have a good idea of just how much of your corporation's data you'll be touching.

STEP 2: IDENTIFY THE OPERATIONS
Now you need to make a list of all the operations or actions that will be done to each object. Entire team participation is definitely desired for this step. At this stage, you should only list basic, single operations using high-level terms. For instance, if the Inventory record is one of your objects, some of its operations include: Read one item, Read multiple items, Update an item, Delete an item, Add a new item, etc.

What if the argument is made that a new item is never added to the inventory without first checking the "product list" record to make sure it exists? Some programmer may insist that since these steps have to be done together, then they must also be coded together. Although the steps will still be done in the correct order, their object and operation identification are done separately. The benefit of this step is that these operations can actually be equated to a future Assembler module or C/370 function. These operations are actually just database access routines whose sole purpose is to handle requests from non-database routines. Here's how the inventory object and product list object maybe described in our design thus far:

OBJECT: Inventory Record
Operations:

1. Add New Item
2. Delete Item
3. Read One Item
4. Read Multiple Items
5. Update Item

OBJECT: Product List
Operations:

1. Search for Item

Note that only the operations that are needed by this project are listed for each object. Furthermore, any action that needs to be performed against an object must be done using a previously specified operation for that object. This concept is called information hiding and eliminates the folly of each programmer writing his own code to access an object and its data. Just think of the hours of coding and testing that are saved when a routine that several programmers need has been already designed, coded and tested.

STEP 3: IDENTIFY YOUR CONTROL MODULES
These are the modules that will receive direct control as the ECB processes the user entry. In other words, these are the modules that are invoked after your ECB is created and your front-end application edits/parses the user entry and determines which module to invoke. List all new and existing modules that fall into this category. Later on, developers will change or code the control modules to invoke the correct object operations we identified earlier. The control modules should NOT be allowed to access the objects directly.

STEP 4: DETERMINE WHAT ALREADY EXISTS
Want to save more time during the coding phase? Determine what code already exists out there that duplicates operations you identified in Step #2. If you or your team are unfamiliar with an area or its objects, it would be wise to consult with someone who's more of an expert in order to quickly identify what code already exists that you can use.

Don't exclude those routines that may only do similar work that you needed for your operations. You may be able to copy those routines later and make changes to them to meet your requirements.

STEP 5: PSEUDO-CODE THE OPERATIONS
Now is the time to decompose the object operations into the low-level steps that each will perform. Use whatever pseudo-code method that the team agrees upon: English-like statements, step-wise refinement, or PDL (program design language). I think its best to allow every team member a chance to participate in pseudo-coding. Be sure to have a thorough review of the pseudo-code by at least two other team members in order to catch design bugs.

STEP 6: PSEUDO-CODE THE CONTROL MODULES
For the new control modules, pseudo-code them using the object operations to access the objects and their data. For the existing modules, only pseudo-code as much as needed indicating where changes would be inserted for either invocations to other control modules or object operations. An example of a pseudo-code for a new control module that handles adding new items to an inventory record is as follows:

START OF PROGRAM

IF ACTION = 'A' THEN

INVOKE "Search for Item" Operation for Object=Product List
IF Error = NOT FOUND THEN

INVOKE "Error Routine" Operation for Object=Inventory
EXIT PROGRAM

ELSE

INVOKE "Add an Item" Operation for Object=Inventory

END IF

END IF

......(more pseudo-code)......

END OF PROGRAM

STEP 7: CODE & TEST
Since TPF is not an object-oriented language, some of the OO terms we used at first won't apply at coding time. So its important to know what's equivalent to what when you get to the TPF coding phase. The following table should be helpful:

OO TERM ......................... TPF EQUIVALENT

Object ...................... Dsect, C Structure, DB2 Table
Operation ................. Assembler module or subroutine, ISO-C function
Control Module ........ Assembler or C module

Its important to get the object operations finished first because they will be the building blocks for the control modules to use. Knowledge of their existence will save countless hours for developers now and in future projects. When developers start to coding the control modules, they'll find that all the database access routines already exists and only need to be "plugged-into" their modules.

RESISTANCE TO THE PARADIGM SHIFT
Anytime a new concept like OOD is introduced into a non-object-oriented environment like TPF, there is bound to be resistance to the change. A lot of programmers still prefer to just go away and do their own thing when they're given an assignment. Adding to the problem is that some developers tend to exercise territorial control over a functional area and resent any intrusion into their "domain". These kind of problems would have to be dealt with before OOD can be fully and correctly implemented in any environment.

The first time I used OOD techniques in a project only two-thirds of the team fully participated in the process. When it came time to use the object operations, some team members still would not use the already coded operations and decided to code their own access routines! The members of the team who used the already coded (and tested) object operations were able to do their assignments quicker and move on to the next assignment while the non-users spent two to three times longer on one assignment. My greatest satisfaction came when I was given a new project that used some of the same "objects" used in the previous project. Because we'd used the OOD approach, I could honestly tell my superiors that about a third of the routines we needed were already coded and ready to use.

FREE UTILITY WITH THIS ARTICLE
This month ACPTPF Today is offering a free software utility for readers wishing to utilize the object-oriented design techniques described in this article. However, this software is available only via download from our web-site at "http://www.tpftoday.com/".

"Object Manager for TPF" is the name of this utility and its purpose is to guide users through the first six steps outlined in this article using a user-friendly, step-by-step interface. "Object Manager for TPF" can also be used to keep a catalog of objects and operations about your system that can be used across multiple projects.

Readers wishing to use this utility will need the following:

-a PC with a Pentium processor
-Windows 95 or Windows NT
-8 Megabytes of RAM
-10 Megabytes of disk space
-VGA monitor with 256 colors
-a mouse