To understand the overall construction of an RPG program you need to understand functional decomposition (FD), the natural process of breaking a complex problem down into its constituent parts. This subdividing continues until the smallest executable parts have been reached.

The purpose of going through this process is twofold. First, complexity and understanding have an inverse relationship. That is, the more complex a problem is the more difficult it is to fully understand. Breaking down the problem into smaller and therefore less complex pieces facilitates its understanding and therefore its ultimate solution. Second, once the decomposition is complete all that's left is to convert the pieces to code. FD actually simplifies the coding process. Lets look at an example.

Suppose our programming task is to write a maintenance program for the company master file. This kind of program is a routine part of business programming, although a complex one for an entry level programmer. Getting past that initial complexity, is often one of the most difficult things a new programmer must overcome. If you think about the whole problem at once (writing a maintenance program) you can easily be overwhelmed by its complexity. The only way you can successfully write this program is to look beyond the problem and identify the individual tasks that collectively make it up.

For an interactive program such as this one the best place to start is with the user's tasks. Interactive programs are driven by the user sitting at the display station making requests to the system. So you start by asking the question "what are the major activities the user will need to do to perform their job?" One of the first things you'll need to do is keep track of the information as you develop it. There are a number of ways to do this, the simplest is to develop a hierarchy chart showing the program at the top--called level 0. The next row below the program will be the top level of functionality, that is the major identifiable tasks the user will need to do

Lets call this level 1. We know the user will at least need the capability to add a new record, change an existing record and delete an existing record. These major subdivisions will make up level 1. Have we gone far enough? You can answer that question with another question. Can I code the task "change a record," "add a record" and "delete a record"? The answer is no. Changing a record involves a number of specific subtasks. For example here is a list of some of the tasks that support the changing of a record.

1. A pointer (key) to a specific record. This requires user input in the form of an id number or social security number pointing to the record the user wants to change.
2. Retrieve the record.
3. Verify the retrieval was successful.
4. If unsuccessful, we need to notify the user.
5. If successful, we need to load it to the display station.
6. Validate the changes made by the user.
7. If validation fails, notify the user.
8. If validation is successful update the record.
9. Query the user for another change.
10. We need to develop display files so the user can interact with the display station. One for the add and change/delete routine and a display file that allows the user to select a task (a menu).

This might seem like a fairly long list for a seemingly simple task but, in fact, it's incomplete. The point is that one item in level 1 has been exploded into a much more detailed level 2. We would then perform the same kind of decomposition to both the add and delete tasks. The next step would be to decompose the second, more detailed level, into its constituent parts. This process continues until we've reached a point where the results of decomposition represent simple functions that can be coded. The end result is a bottom level of highly detailed tasks all of which make up our program.

How do we know when we've reached the bottom level? A general rule is "if you can code it" you've gone far enough. Remember, however, coding means single functions. The whole point of decomposition is to reach a point where the complexity has been reduced to a manageable level. Once that point has been reached it's a waste of time to go any further. Once our decomposition is finished we've reached a point where we are ready to begin coding our program. Coding anytime before reaching this point is asking for problems.

Will this approach guarantee success? No, but it will increase the odds of your getting to your goal in a timely and efficient manner. In addition, the process outlined above makes intuitive sense, provides success on every pass rather than a long messy debugging process and finally, clarifies and simplifies an otherwise complicated process.

Even though programming is very hard work, it should be more fun than struggle.

RR 2 Box 168, Jericho, VT 05465, 802-899-3115 Info@lavalleeccs.com