Procedural oriented analysis, design and programming - The world before OOAD

Before going in to discuss what is OOAD, we have to understand how we 'think' usually.

While there could be many thinking that exists before OO, it is very common to think in procedural oriented way as that was the latest development before OO has come to party.

So what is that thinking and what is the procedural way, a short recap:

As the software development happens only when there is a requirement, let us take some requirement.

Let us take the example of coffee maker.

Here is what our coffee maker can do:

With these requirements, lets discuss the way of implementing it.

Lets break the requirement and come up with the functionality breakup (name of the functions tells what the function does). Generally the functionality can be broken in a way what a system can provide, can take, what it notifies and for what it reacts and how it reacts.

What it can provide:

1. makeFilterCoffee
2. makeEspresso
3. makeLatte
4. makeCreamCoffee
5. outputWater
6. outputMilk

What it can take:

1. retrieveWater
2. retrieveMilk

What it notifies:

1. notifyLowPowerInputSupply
2. notifyLowMilkInputSupply
3. notifyLowWaterInputSupply
4. notifyLowBeanInputSupply
5. notifyProductReady

For what it reacts: 

1. isPowerButtonOn
2. isWaterSufficient
3. isMilkSufficient
4. isCoffeeBeanSufficient
5. whatInput

How it reacts:

1. isPowerButtonOn - If the power button is on, then the coffee maker boots up. If the button is off, then the coffee maker is switched off.
2. isWaterSufficient - If the water is sufficient, then it continues the operation. If the water is not sufficient, then it notifies and discontinue the operation.
3. isMilkSufficient, IsCoffeBeanSufficient - These work similar to isWaterSufficient
4. whatInput - Based on the input selection, the coffee maker provides the output.

With the above analysis, we can identify the functionality and proceed with the design and from there any one can take the implementation forward.

The first step in procedural oriented design is to define procedures for the above identified functionality and break it as small as possible so that code can be res-used from. (this is the base of procedural oriented design).

And the next step is to group these functions so that those small functions are accessible easily. How we group those functions can be influenced by the requirements, easy of code reuse, easy to extend.

In the above use case, we can group them in following are few different order

1. Like how they have been listed above
2. Based on the items involved in the coffee making
1. Functions which deals with Coffee bean
2. Functions which deals with Water
3. Function which deals with Power
4. Functions which deals with Milk
3. Based on the process involved in the coffee making
1. Functions which deals with all the input
2. Functions which deals with all the machine process
3. Functions which deals 

There could be many such groupings.

Next thing in the design is how to handle the different behaviors. In any methodology, it need to be handled by different state of the application / machine. That is in the above case, coffee machine exhibit different behaviors in different states. In procedural design, the states are represented by variables. Local or Global or Scoped variables.

These state variables are usually grouped together according to the related functions and kept separately away from the functions. They are included wherever they are required and hence they always represent the updated state when one functions updates the state with the latest value according to the current execution (i.e. according to the flow).

And that's the major part of the story in procedural oriented analysis, design and development. The rest of the story is how to implement, how to tune the application for better performance based on the use cases, OS and the compiler.

The majorly used language for procedural oriented development is "C" where most of the today's engineers would have started their career. In C, these groupings happens in the header file  (the famous .h file) and it gets included (#include compiler directive) whenever it is required. The functions are the functions with the return value, function name and arguments. In C, we have the pointer concept where we can have "reference" to the entities which makes the things really easy and efficient as it avoids memory copying, more variables which means lesser maintenance. But at the same time, since we have directly access to the entities (memory, devices and referred variables), if a good principle is not followed properly and which is the case most of the time (at least initially), the chances of memory corruption, memory leak and hence the applicable instability is very high.

Also if the grouping of the items is not chosen correctly (which itself is a vague word in the world of changing requirements), it is really tough to add functionality.

This means as when more and more requirements comes, chances are high that an application becomes in-maintainable.

So how to handle it.

Answer: Better practices from the lesson learnt. And that's make the beginning of the journey to OOAD.