Microsoft Word F. Asagba 2 Nig doc

Modular Programming
Many programs can be decomposed into a series of 
identifiable subtasks. It is a good programming 
practise to implement each of these subtasks as a 
separate program module. The idea of modular 
programming is to sub-divide a program into smaller 
units that are independently testable and that can be 
integrated to accomplish the overall programming 
objective (Abott, 1993). The use of modular 
programming structure enhances the accuracy and 
clarity of a program, and it facilitates future program 
alterations (Louden, 1993).
One motivation for modularizing a program into 
methods is the divide-and-conquer approach, which 
makes program development more manageable by 
constructing programs from small, simple pieces. 
Another is software reusability - using existing 
methods as building blocks to create new programs. 
Often, you can create programs mostly from 
standardized methods rather than by building 
customized code. A third motivation is to avoid 
repeating code. Dividing a program into meaningful 
methods makes the program easier to debug and 
maintain (Champeaux, 1990), and (Deitel, et al, 
2007). 
Top-Down Approach 
When developing a new program, the overall 
program strategy should be completely planned out 
before beginning any detailed programming. This 
allows you to concentrate on the general logic, 
without being concerned with the syntactic details of 
the individual instructions. Once the overall program 
strategy has been clearly established, the details 
associated with the individual program statements can 
be considered. This approach is generally referred to 
as “top-down” programming. With large programs, 
this entire process might be repeated several times 
with more programming details added at each stage 
(Louden, 1993). 
In top-down design, the main program is first defined 
and then the remaining modules or units are 
specified. The central idea in top-down programming 
is that the design must progress from the general to 
the specific, each program unit being progressively 
refined. Usually, the main modules drives or co-
ordinates the other modules specifying what each 
subprogram should do. It is also expected that the 
main module be the interface between the entire 
program and users. The hierarchical relationships 
existing among modules of a program are often 
displayed in a structure chart. This chart conveys the 
sense of orders and module or task is represented 
with a rectangle and modules are sub-divided at each 
level until they can no longer be sub-divided further. 
Fig. 2 shows a structure chart. 
Fig. 2
Structure chart 
As seen from the structured chart above, the main 
program is at level 0. This main program is divided 
into three modules as the application requirements 
grow. This is a major advantage of modular 
programming. The top-down design methodology 
often employs a process referred to as stepwise 
refinement or divide-and-conquer whereby the 
situation is progressively refined till the lowest level 
in the structure chart is reached. This process of step-
wise refinement is also very often applied to the 
specification of the lower level procedures. 
Top-down design is often referred to by other names - 
structured design, composite design, programming by 
stepwise refinement, and so on. Though the names 
Module 1 
Module 2 
Module 3 
Module 1.1 
Module 1.2 
Module 1.3 
Module 3.1 
Module 3.2 
Main 
program 

---

A Comparative Analysis of Structured and Object-Oriented Programming Methods
 
* Corresponding Author: Asagba, Prince Oghenekaro 
43
differ, a uniform approach is generally agreed upon: 
we identify first the major function to be 
accomplished, then we identify its sub-functions, 
their sub-functions, and so on, proceeding from the 
major function to any number of lesser functions until 
we are satisfied that we fully understand the nature of 
our solution algorithm. The top-down design process 
consists of a series of steps to define the functions 
required for the solution of a problem, in terms of the 
problem itself (Pressman, 2005).