Probably the most well known software development paradigm is the procedural paradigm. Brookshear [1997] says that the procedural paradigm "represents the traditional approach to the programming process. Indeed, the [procedural] paradigm is the one on which a CPU's fetch-decode-execute cycle is based. As the name suggests, the [procedural] paradigm defines the programming process to be the development of a sequence of commands that, when followed, manipulate data to produce the desired result." Notice that the procedural paradigm approaches software development in a way that matches the underlying hardware of a typical personal computer. The processor of the computer works by getting a single instruction, interpreting it, and finally executing it. The procedural paradigm matches this architecture by guiding the development of software so that it has a sequential logic. As a result, procedural programs can be traced from beginning to end so that the entire logic of the program is a series of instructions. This match between the hardware and software usually results in programs with high execution efficiency.

To understand the procedural paradigm, consider the following design problem. Suppose a software designer wants to create a sort routine that inputs a list of numbers and outputs the numbers in sorted order. According to the procedural paradigm, how should this design be developed? First, the problem is decomposed into the various subtasks required for sorting: input, sorting, output. Next, each of these tasks is further divided into relevant subtasks. For sorting, some relevant tasks are finding the smallest number and swapping numbers. Following this process of task decomposition, the entire design is divided into logical units which represent modules and subroutines. The diagram to the right shows a completed design for the desired sort routine. Modules are represented as gray boxes while subprograms are represented with blue boxes. The diagram also depicts a larger context within which the sort routine is integrated. This context could be a spreadsheet program, a database, an email reader, or any other software product which incorporates sorting.

Once the task decomposition of the design is complete, the individual subprograms are coded, tested, and integrated to form a Sort module. Click the boxes in the design above to see a possible implementation of the Sort module in pseudocode. For simplicity, the boxes for Input numbers and Output sorted numbers are abstracted into a single subprogram call in the Sort module. For more discussion on the logic of the Sort module, see the Programs lesson in the Programming Languages module.

One of the primary characteristics of software designed with the procedural paradigm is sequential logic, that is, the flow of program logic can be traced from start to finish. For the sorting routine described above, the logic can be traced through the various calls to the subroutines. To see this take place, launch the Selection Sort applet below, and use it to sort a list of three numbers. The "Next Statement" button at the top of the applet will advance the program trace one statement at a time. When prompted, enter "3" for the sort size. Also when prompted enter the numbers to be sorted: 3, 1, 5. Continue tracing the program execution until the numbers are in order.

The diagram to the right represents the flow of control through the Selection Sort applet when three numbers are sorted. Each of the colored boxes corresponds to a module or subprogram that exists in the applet. The main module, Sort numbers, runs the entire length of the diagram and is responsible for calling all the other subprograms. The circles inside the boxes represent the executable statements of the module or subprogram. The first four blue boxes are the calls to the Input numbers subprogram and correspond to the input of the sort size (3) and the numbers to be sorted (3, 1, 5). Below these, the red box represents the Selection sort subprogram which makes two calls to Find smallest number and Swap numbers in order to sort the numbers. The final three gray boxes represent the Output sorted numbers subprogram which is called three times to output the numbers in order.

Notice that the relationship between Sort numbers and Input numbers is sequential. When Sort numbers calls Input numbers, the flow of control immediately changes to the Input numbers subprogram. The code in Sort numbers does not continue to execute until the call completes (i.e., the execution of Input numbers finishes). When this happens, the flow of control returns to Sort numbers at the exact place where the subprogram call was made. This sequential relationship between calling module and called subprogram is always the same in the procedural paradigm. Hence the diagram represents each call with a pair of arrows that originate and terminate at the same point. By following these arrows through the diagram, it is possible to trace the exact execution path of the Selection Sort applet.

References