Procedural Approach

The best way to solve a problem is to break it down into smaller parts and solve each of the smaller problems. The solutions are then aggregated (collated) to solve the overall problem. Think of each small problem as a task. To perform a task; you write a block of code called & procedure. You can call one procedure from another.

Procedures can be grouped together to form a module. All the modules integrated together form the software system.

This approach to software development is module centric and is not ideally suited for developing complex software. The procedural approach concentrates on the processes of the application. As a result, the modules of software constructed are so tightly interwoven and interdependent that it is difficult to separate the, construction of one module from the other. Reusability of the software becomes difficult as complexity increases with processes.
The employees of an organization can be grouped according to the functions they perform and then arranged in a hierarchy. Similarly, you can simplify the software complexity of a system by breaking the system into modules and arranging them in a hierarchy.

The PC, for example, is a moderately complex system. If we take a closer look, we will see that most PCs can be broken down into various components. These components can be broadly classified as the CPU, the monitor, the keyboard, and storage devices.

The CPU itself can be broken down into its component parts: ALU, math co-processor, and clock. Thus, an entity as complex as the PC can be broken downs to the smallest component such that we know the working of each component. While each component has its own function, the combined operation of each of these components makes the PC function as a cohesive unit. When you break it down into its components and analyze the functioning of each part, you get a clearer picture.

In other words, instead of trying to understand the working of the PC, it is easier to determine what components the PC is made up of, define their functions, and then determine how these components interact with each other.

In the procedural approach, portions of the code are so interdependent that the code in one application cannot be reused in another. Thus, if a module of an airline reservation application prints airline tickets and we want this module to be used to print railway tickets, it would not be possible.

Another outcome of this tight interdependence between modules is that such software is not resilient to change. By this, we mean that the software is not flexible enough to absorb changes. Since application areas! keep improving, software designed for them must keep track of the changes. In a procedural approach, such j a change would mean rewriting huge portions of code. As a consequence of this lack of resilience, software; maintenance costs become very high.

Given the drawbacks described in the procedural approach, it was natural that software engineers started looking for better approaches and methods for developing software.
People have often asked why software cannot be constructed the way an aircraft or a high-rise building is constructed - by putting together several small constituent components to build the whole.
In an attempt to solve the problems inherent to the procedural approach, programmers turned to the object-oriented approach.