Benefits Uses of Structured Programming

One way to tell whether structured programming is a good way to approach a problem is to ask yourself whether a flow chart can easily be used to document the problem. If the answer is yes, then the flow of control is probably deterministic enough that structured programming fits the problem. On the other hand, if the answer is no, then you probably need a more sophisticated, object-oriented approach.
Flow charts have fallen out of favor among programmers over the last decade or two, in large part because the programs people began writing no longer fit the deterministic, structured programming, flow chart mentality. New styles of diagrams have been invented to handle the more free-wheeling programs developers are coding today; these object and class diagrams are discussed in upcoming modules.
A few people may object that the programs simply grew too large to be organized into flow charts; although that's true, it is also the case that structured programming is insufficiently powerful to handle large programming projects. The numbers are fuzzy, but generally any program beyond about 50,000 lines of code will be extremely difficult to develop and maintain using purely top-down design and structured programming. Solid object-oriented design raises the limit to around a million lines of code. Indeed, abstract data types are an object-like means of raising the bar on the size of programs that can be written in a purely procedural language.

Past a million lines of code, even object-oriented design begins to break down. The largest single programs in existence that I am aware of border on 10 million lines of code and are extremely difficult to debug and maintain. New techniques are needed that allow truly huge programs to be both built and maintained.
This is not to say, of course, that these techniques can't also be used for more complicated programs such as games, word processors, operating systems, and spreadsheets. In fact, they have been used for these things for many years, sometimes with great success, sometimes with spectacular failure. If you investigate the successes, you'll often notice that developers adopted object-oriented principles like data encapsulation even though the language they were coding in did not explicitly support it.
But it is my contention that procedural programming is not the best approach to take for these problems, that OOP more closely matches the way these programs are designed and used, and thus enhances programmer productivity.

Traditional, structured, programming has worked well for millions of programs and billions of lines of code. There is no reason to throw it out completely. In particular, it's worked extremely well for number crunching and data processing programs that run once and produce an answer.
Two characteristics tend to define problems that can be addressed well in a purely structured fashion:

1. The data to be manipulated closely matches the built-in data types of the language, typically numbers and strings.
2. The program follows a well-defined flow of control to produce a single result based on some input.

Computer programs with these characteristics include many scientific, engineering, and text processing applications and many of the "textbook examples" from traditional computer science courses. Not surprisingly, these are exactly the sorts of programs that the first people to invent programming languages wanted to solve.

Most modern programming languages are structured this way: the things in the program are objects, and most of the code in the program consists of methods that use the data stored in those objects. A traditionally structured program usually has control over what happens when, but an event-driven program must be able to respond to input at unpredictable moments.
Structured programming can be defined as a software application programming technique that follows a top down design approach with block oriented structures. This style of programming is characterized by the programmers tendency to divide his program source code into logically structured blocks which would normally consist of conditional statements, loops and logic blocks. This style of programming has the implementation of the source code being processed in the order in which bits of the code have been typed in