What Is Software Design and Why Is it Needed?

As you approach the door of the small shop where you’ve picked up your dinner a hundred times before, the front door is closed, but the smells from inside seem—if it were possible—to come right through the glass.
You grab the big, brass, door handle, look straight at the large prominent sign that says PUSH, and give the handle a pull—exactly like you have done every other time in the years you’ve been coming here. “D’oh!” you exclaim, sounding very much like Homer Simpson.
Have you ever had an experience like this? Why is it that you, an intelligent, educated person can’t read a large, prominently displayed sign, and follow a one-word instruction?
Why does everyone pull instead of push when presented with a door like the one shown below? What does this door say to you?

The answer is really very simple:

because the door handle itself is a sign, a sign that says more fundamentally and forcefully than the written sign above it, “PULL!!!” 

The problem is not with your ability to read, but with the “designers” of the building who combined an inward-opening front door with a door-pull instead of  a push-plate.

Someone made a fundamental design error, and all the user-friendly instructions in the world won’t fix it.

What is design? What are the design fields, and how are building design (architecture), graphic design, industrial design, and software design similar?
As you ask these questions, you’ll discover many different viewpoints:

1. those who see design as science,
2. those who claim design for engineering, 
3. those who feel design is an art, and 
4. those who insist that design is (or should be) a profession like law or medicine. 

Let's explores those ideas as well as the common concepts of

• modeling, 
• abstraction, 
• structuring, and how all of these ideas relate to developing software;

after all, what you really want to do is to turn out a great program, right?
To do that, you will learn:

• How to distinguish between different design philosophies and viewpoints.
• Why design is needed.
• How to describe the basic goals of design: “firmness, commodity, and delight.”
• How to recognize the basic problems of design: essential and accidental complexity.
• How the fundamental tools of design—models, abstraction, and decomposition—can be used to attack the basic problems of design.
• How software abstraction mechanisms can be used to simplify the building of software, enabling you to build better programs.
• How software design methodologies help the software designer approach different parts of the design problem.
• How object-oriented design and structured design are related, and the basic terms common to each.

                                   What Is Design?

“One of the main reasons most computer software is so abysmal is that it’s not designed at all, but merely engineered.”

You might be surprised to find out that these are not the words of some disgruntled Luddite or some ivory-tower academician. The speaker was Mitch Kapor, the designer of one of the most popular software packages of all time (Lotus 1-2-3) and also the author of “A Software Design Manifesto.” Originally given as the keynote address at Esther Dyson’s PC forum in 1990, Kapor’s manifesto has been widely reprinted in the ensuing years.

In it, he argues for the creation of a new type of software professional: the software designer, who fulfills the role that an architect does in building construction, making sure that a building meets the needs of its inhabitants.

Almost everyone would agree with Kapor, (although, after your latest software crash, you might think that software is neither designed nor engineered).

How to actually design good software is the real question.

The ancient Roman architect Vitruvius considered a similar question:

what makes a good building?

In his treatise De Architectura Libri Decem (Ten Books on Architecture), written in 29 B.C., he proposed three principles that many think provide a good starting point for evaluating software designs.

A well-designed building, said Vitruvius, should have the qualities of commodity, firmness, and delight. 

Notice, that a product that balances commodity, firmness, and delight does not necessarily possess an equal amount of each.
E.g. most people think a good cup of coffee should contain more coffee than cream or sugar.

• When you buy a software package, you want it to do exactly what the box says it will do. This is the characteristic of commodity—the program is effective in the sense of being well fit for its purpose. 
• You also want the program to be well built: you want it be as fast and small as possible, and to continue working in a wide range of situations. This is the characteristic of firmness. 
• Finally, you want your software to be attractive and pleasant to use. In a sense, you “live inside” your software, and it’s important that the interface be both functional and aesthetic. This is the quality of delight.

Each of these qualities is important.
Good-looking software that doesn’t run well or is hard to use is no better than software that is fast and efficient (that is, software that uses as few resources as possible) but doesn’t do what you want or does it in an ugly or unappealing way. 

Software designers, like all of us, tend to see the design process through their own particular lenses and to concentrate on one specific aspect or method of designing programs. 

1. Some see software development as a scientific endeavor. 
2. Others see it as an engineering exercise. 
3. Still others think of designing computer programs as artistic expression, like painting or music .

                              DESIGN AS SCIENCE

How do you become a lawyer or doctor? You go to law school or medical school. But, what do you study if you want to design computer software? If you’re just embarking on your academic career and you ask this question, almost certainly you’ll be encouraged to major in Computer Science.
Are software designers scientists, and, if so, what does such a science entail?
You might have heard the old joke,

“You can tell if something’s a science—it doesn’t have the word science in its name.” 

And there’s some truth to this observation. All of us agree that physics and astronomy and chemistry—the so-called hard sciences—are really sciences.
But how about political science or military science or social science? How are the so-called “soft” sciences different from physics and geology?

Nobel prize winner Herbert Simon, one of the founders of the Computer Science department at MIT, attempted to answer this question in his 1969 book, The Sciences of the Artificial.
 According to Simon, there really are two sorts of sciences:

• The natural sciences—physics, chemistry, biology, and geology—which are concerned with the discovery of the natural world—finding out “how” things work, and building workable theories of explanation.
• The artificial sciences—political science, the social sciences, engineering, and computer science—which study things that have been built by humans, rather than naturally existing phenomena. Unlike the natural sciences, the artificial sciences are concerned with how things should work, not merely how things do work. An engineer wants to find the best way to build a bridge and a doctor wants to find the most effective method of treatment. All of these are issues of design.

Science, then, is about the study and discovery of general principles (theories), and the artificial sciences apply those theories to man-made artifacts, including the design of software. Software design, from the scientific point of view, includes

• Theories that deal with structure and representation.
• Rigorous and formal techniques for evaluating properties of designs.
• Formal methods for choosing the optimal (or at least a satisfactory) design from a set of possible designs.

Reading this, you may be thinking, “what does that have to do with writing a word processor or spreadsheet?” Think back to the goals of design—to create artifacts that  exhibit firmness, commodity, and delight.

The role of the computer scientist is to provide an objective, rigorous, theoretical foundation for constructing software that exhibits firmness.

                          DESIGN AS ENGINEERING

“The scientist builds in order to study; the engineer studies in order to build.”

These are the words of the universally acknowledged father of software engineering, Fred Brooks, who was also the founder of the Computer Science Department at the University of North Carolina at Chapel Hill. His book, The Mythical Man Month (recently re-released in a nth anniversary edition), was written after the completion of one of the largest software development projects ever attempted: the design and construction of the operating system for the IBM System/360. For those designing or managing the construction of a software product, it remains a unique and indispensable information resource

For Brooks, the difference between the engineer and the scientist is not so much what they do, but the purpose behind their work. Software engineers design software in much the same way that mechanical engineers design bridges, industrial engineers design cars, and construction engineers design houses and auditoriums.

What does the software engineer design? Tools: tools for writing, tools for computing, tools for communicating.

The software engineer succeeds only to the extent that he builds a useful tool. 

To quote Brooks, “That swordsmith is successful whose clients die of old
age.”

“This is more like it,” you might be thinking. “I understand that engineering is about building things, and it seems obvious that the software that I use could benefit from some engineering techniques.” You’re right.

Like the computer scientist, those who see software design as engineering are concerned with the quality of “firmness.” Building on the foundation of computer science—the fundamental data structures and algorithms discovered and constructed there—the software engineer builds “things that work.”

Many of the techniques, such as

1. the various diagramming techniques and 
2. the rules of thumb about class design,

have their origin in the software engineering community.
Software engineering is essential for well-designed software, but, as Kapor pointed out, it is not enough


                                          DESIGN AS ART

If software development is an art, are software developers artists? How far can the notion of “art” be stretched?
“Look,” said the hopeful student to his long-suffering advisor, “everyone who watches Michael Jordan or Giannis Antetokounmpo play says he’s a real artist. So why can’t I get art units for playing basketball?” The reason, of course, is similar to the reason that computer science students don’t receive foreign language credit for learning C, Pascal, or Java: because the word “language” means something different in each context.
The same can be said for the word “art.” In one sense, a good basketball player is an artist, but in another, very real sense, basketball players are not artists at all.

What, exactly, do we mean when we talk about design as art? The fine  arts—painting, drawing, sculpture—exist to provide an aesthetic experience.

Though it’s conceivable that you could write a program whose primary purpose was aesthetic, in the ordinary course of things you’ll probably never do that. But, if we consider the applied arts—the construction of artifacts that are both useful and aesthetic—then software design certainly is one of the arts, in much the same way that graphic design or industrial design is.

The purpose of graphic design is to create documents such as books and magazines in which the aesthetic structure, the use of type and color and layout, serves the message that the piece conveys in a way that the reader can readily appreciate. 

In industrial design, the designer tries to create appliances or automobiles that are both attractive and functional. Of course, balancing functionality and aesthetics is not always easy. 

Think of the tail-fins on the 1958 Cadillac! Though at the time many people thought them attractive, most people today see the non-functional tail-fins as a case of wretched excess.

“Well, I don’t know,” you might be saying to yourself. “I’m not really artistic, and it seems like all this stuff is just a little superfluous.” You have a point. Adding an “artistic” gloss to  an aging and infirm superstructure is seldom successful.

You might even find yourself writing software that has no visible interface—embedded or systems software, for example. In such cases, arguing for “good-looking” programs is a misplaced concern.

Most of you, though, will write software for other people to use, and when you do, you take on the role of the artist-designer, striving to inspire delight, as well as commodity and firmness. This is a difficult role.

Software (at least good software) doesn’t just lie there and look pretty. Instead, it involves its user in an interactive experience. Not only do you want your program to look cool, you want it to act cool as well.

The demands of your role resemble those under which a playwright works. You must strive to get all the actors to line up and say their lines in a way that leaves the audience begging for more. However, your job is tougher still. The piece you’ve been commissioned to write is a more like a “murder-mystery dinner” where the actors and the audience intermingle. Your job is made doubly difficult because you have to anticipate the unscripted actions of your diners, and provide contingent lines for your players to use when things go off on a tangent.
If all this seems a little vague and abstract to you, you’ll be happy to know that designing software that is attractive and a pleasure to use does not require an “artistic temperament,” or the talent of pop artist David Hockney or playwright Neil Simon (RIP).


                                    DESIGN AS ARCHITECTURE

If “firmness” is the special purview of the engineer-designer, then “delight” has a similar place in the world of the artist-designer.
Yet, concentrating on firmness and delight is not enough; the designer must also be concerned with commodity, balancing form and function. In this regard, many software designers see a close parallel between their role and that of the architect.
This analogy was the central theme of Mitch Kapor’s “A Software Design Manifesto,” and the similarities between software design and architecture have greatly influenced the “patterns” movements.

Like the artist, the architect wants to build structures that are visually pleasing; 

visual design is central to every architect’s training.

But, like the engineer, the architect wants to build structures that stand the test of time. 

The science of materials and construction techniques is an important part of an architect’s training.

In the end, the architect designs neither for beauty nor for durability, but for the client. The architect’s goal is to build a structure that meets the client’s needs.

                              The Process of Design

“So,” you say, “you’ve talked about science and engineering and art and architecture. Let’s not beat around the bush! Just what is design? How do you go about it?”
Those are two very good questions, and they deserve a direct, if not exhaustive, answer:

• Design is preliminary; it’s done before construction. Designing and building a house are two different activities.
• Design uses models. One dictionary definition of design is “to plan by making preliminary sketches or outlines.” A design may use several different models, but the models are all distinct from the creation.
• Design has a goal: to create artifacts for human use. The designer acts as an agent for the client, and needs to ask “does it work?” not only in the mechanical sense of running without error, but “does it work?” in the larger sense of meeting the needs of the client.
• Design is a process, yet the same process may not be applicable to every artifact. A process appropriate for designing a computer game might place a high emphasis on spontaneity and creative intuition, while a process used to develop a heart monitor or a missile-defense system might, appropriately, be much more formal and rigorous.

                                       WHY DESIGN IS NEEDED

If you are a student who has written a few programs, or if you write software for your own use, you might be asking, “Why bother? Why not just start coding?” Though some software projects may not need a long or formal design process, nobody with substantial experience sits down at the keyboard and just bangs away with no thought or reason. And, though an informal design process might be appropriate for most of the work you do, learning about more formal processes can help you to consider aspects of software design you have previously ignored.

Design is the planning process you go through before you build something. But again, why bother to plan at all?

• The major reason is that it’s cheaper to change your mind while you’re planning something than after it’s half built. This is true for buildings, of course; erasing a line on a blueprint is much less expensive than ripping out a wall. For software,the same thing is true. A change that may cost $100 to make while you are designing your program can cost $1,000 to make after parts of the program are already built, simply because so many other parts have to be adjusted. And, if you find you have to make the change after the program is finished and in operation, the same change can cost $10,000 or more. “Look before you leap,” is more than just a hoary old cliché.

More broadly, design involves an attitude that seeks to identify alternatives and
intelligently choose an appropriate course of action. Good design involves

1. analysis,
2. reflection, and the 
3. development of insight.

The way in which design is done has changed over time, as such insights have accumulated.
In the 16th century, if you wanted to build a house, you wouldn’t work from a set of blueprints created by an architect and given to a contractor. Instead, you would hire a master-builder who would build your house based on his own experience and the experience of the master-builder who had trained him. Today, the development of a common language—the blueprint—and a common process (supported by such things as the Uniform Building Code and the licensing of building contractors) enables you to build a house by any number of firms, with little variation in the output of the finished product.

This “separation of concerns” is one of the factors that leads to a more efficient process

Today, if you decide to build a house, your architect acts as your agent, making sure that the house meets your needs.
To do this, the architect uses many different types of models—not only blueprints, but sketches, mock-ups, and even style books of common house types and floor plans, etc.
Normally, as a client you review the sketches and mock-ups, whereas the building contractor relies on the blueprints.

These models help the parties communicate and record the respective decisions they make. 

Your builder does not decide, halfway through construction, to add a stairway to the west wing—at least not without consulting the architect.

This whole system works because of the availability of different models—at several levels of detail and abstraction—and a common agreement among all the parties about how those models correspond to reality.

                              THE PROBLEMS OF DESIGN: WHY IS SOFTWARE HARD?

If design—the use of planning and models—has been so successful in architecture and engineering, why can’t we just apply to software the same principles used to make buildings, bridges, and cars?
Is designing a piece of software the same as designing a bridge—or a computer? There is a lot of evidence to suggest it is not; that software design is fundamentally more difficult than engineering skyscrapers. Professor Brooks, in
his famous article, “No Silver Bullet,” tells us why.

Perhaps you’ve had a dream like this. You are taking a walk with your sweetheart. You turn to look into each other’s eyes, and, as you watch, your loved ones turn into something different— something horrible. You wake in a sweat, with your heart pounding. This primordial fear— the familiar changing into the unknowable and fearful—is at the heart of the medieval legend of the werewolf. In the modern retelling of the legend, the only hope for deliverance is the “magical” effect of a silver bullet. And, if you’ve ever worked on a piece of software that seems to have grown ravenous and rapacious, the metaphor seems especially apt.

Why is designing software more difficult than designing a bridge? Because software has four essential qualities that resist easy solutions:

• Software is complex.
• Software is unprincipled.
• Software changes.
• Software is invisible.

Software is complex because it contains so many “moving parts.” A modern jet fighter plane may contain a few thousand moving parts. A software system of even moderate size may contain tens of thousands of lines of code, each of which must correctly “mesh” with the rest of the system. Every additional line of code, every new condition or event, leads to the possibility of new conditions, previously unconsidered, or overlooked.

Software is “unprincipled” because there are no known fundamental and unifying laws that can cause software programs to “make sense.”

Software programs are written not to conform to a regular universe, but to the arbitrary, capricious, and illogical mind of man.

Software changes because it is so malleable. Although the London Bridge was moved to Lake Havasu, Arizona, that was an event both expensive and uncommon in bridge-building lore (Plus, the bridge remained essentially unchanged).
By contrast, software is moved, twisted, and distorted with such regularity, and with such little foresight, that it’s a wonder that any of it works at all.

Finally, software is invisible. Any design problem involves two translation steps. The first step is the translation of a mental(or conceptual) model to an abstract model.
Suppose you decide to splurge on a new, custom designed hot-rod. Your conceptual model is the picture in your mind. The designer’s first task is to translate your mental model into a specification. This specification may include textual parts—the type of engine, and the brand of tires—but most of the specification will be visual: sketches, scale models, and photographs of similar cars. When designing software, this translation is much more difficult, as Figure  shows.

Prototypes and interface builders have done much to make the “external face” of a program visible, and software engineering diagramming techniques are of considerable value; but, in the final analysis, the “mapping” between an abstract model and a finished software product is much more tenuous than that for
buildings, cars, or dresses.



                             The Designer’s Toolbox

Software, then, because of its very nature, is hard to design. But hard is not impossible, and, while the problems presented by complexity, change, and invisibility don’t have magical solutions, they do have solutions.


                                     MODELING AND MODELS

You’ve seen the word model bandied about, but what, exactly, is a model?

A model is a representation of something else: something real or imaginary. A model can be textual, mathematical, graphical, or can use some other form of symbolic representation. 

The supply-demand curve in economics is a model of a social interaction.
J.R.R. Tolkien’s The Lord of the Rings is a literary model of an imaginary world. A map is a model of our physical world.

How is a model different from what it represents?

A model is an abstraction. The globe on your desk is not the real earth; your Thomas’ Guide is not really your town; Tolkien’s novel is not Middle Earth; supply and demand is not the buying and selling of hot dogs and off-road vehicles. 

Instead, abstraction lets us model the thing we’re studying by ignoring the irrelevant elements and concentrating on the essential.





   ABSTRACTION, COMPLEXITY, HIERARCHY, AND DECOMPOSITION

“Why on earth,” you say, “would I want to ignore details? What do I gain from that?”
A good way to illustrate the importance of ignoring details is to compare a street map with a photograph of the same area taken by a LandSat satellite. Which is clearer, a street map or a satellite map?

Taken from space by high-resolution cameras, the satellite photo will let you count the blades of grass on your lawn. Yet, with all this incredible detail, it’s almost entirely useless for finding your way across town. It doesn’t have too little detail for this purpose; it has too much.

As you’ve already seen, one of the essential elements that makes software hard is its complexity. Human limitations—our memories and our senses of perception—prevent us from comprehending and dealing with very complex situations without the help of a simplifying model.
For instance, social systems simplify our relationships with each other by proscribing behavior (through laws) and describing roles (through government).

You can use such models both to understand the world, and as a tool to create  artifacts.

Faced with the multitude of different animals in the world, you group similar animals together into classes based on their similarities to each other. You can arrange those classes into a “pyramid” (or hierarchy) based on the similarities of each class to other classes.

When you encounter a creature that is 1/4 inch high and has six legs, you put it in the insect category.

Creating such categories gives you a mental tool you can use to deal with individual animals. 

Can you imagine what your life would be like if you didn’t do this? If you were bitten by a snake, you’d have no reason to avoid others.

A special form of classification, decomposition, is useful as a tool for creating solutions, not merely for understanding. Decomposition is not merely recognizing similar “things,” but recognizing that most big things can be broken into simpler things, and those simpler things into still simpler things. 

Trees have branches, leaves (or needles), roots, bark, and trunk, and the countless types of trees have innumerable variations.
But, when you decompose a tree you find it is composed of simpler structures known as cells, and that the cells themselves are composed of simpler pieces yet—molecules and atoms.

Most human artifacts exhibit similar structure, and such structure can usually be described in the form of a hierarchy or decomposition.

            Design Solutions in the Software World

Architects have been designing buildings for thousands of years, and thinking about design nearly as long. Vitruvius wrote his books laying down the principles of firmness, commodity, and delight over two thousand years ago.
In comparison, the computer was invented yesterday, and we may someday regard today’s latest software creation the same way we regard Stonehenge in comparison to the Acropolis. Perhaps the golden age of software development is just ahead.


               SOFTWARE ABSTRACTION MECHANISMS

Short though the history of software design has been, the ideas of

• abstraction,
• decomposition, and 
• hierarchy

have played an important part.
Originally, computers were somewhat simple, and programmers could keep all the relevant details straight in their minds. As programs got larger and (subsequently) more complex, these principles were used to create various software abstraction mechanisms that were brought to bear in an attempt to master complexity.

The first programmers worked almost directly with the “naked” machine.

A very thin abstraction, numbering memory locations to give some order to their seemingly unlimited (perhaps 12K) reserve of memory, was the only concession. 

Unfortunately, even 12K of memory, which seems laughably small today, is too much complexity for our brains to handle. Named variables (the ability to refer to GROSS_PAY instead of location AF3CH) enabled programmers to handle more complex problems by hiding an unnecessary detail—the actual physical location where GROSS_PAY was stored

Just as the ability to name variables enabled programmers to hold bigger “chunks” of a program in their minds at a time, the ability to name sections of code (called named subroutines) enabled them to think of their programs in still larger pieces.
These two advances, both of which involved ignoring irrelevant details, increased the productivity of programmers more than ten-fold. So, what do you suppose they did? That’s right, they wrote programs that were ten times larger, and then some. And, just as you might expect, the additional complexity rendered those programs unmaintainable and unreliable.


        THE SOFTWARE CRISIS AND STRUCTURED PROGRAMMING

In the late 1960s, the Department of Defense (DOD) was one of the largest purchasers of custom-made software. No doubt you’ve heard the stories of the $900 ash-trays. But even for folks accustomed to those sorts of apparent extravagances, the problems with software had gotten out of hand. In a pair of conferences sponsored by the North Atlantic Treaty Organization (NATO), two memorable terms were added to the software development lexicon:

• software engineering and 
• the software crisis.

The term software crisis was coined to describe the fact that software was consistently late, over budget, and buggy.
“Why can’t we get software on time, at the price agreed upon, and why doesn’t it work as specified?” NATO asked.
The prescription of the experts at the conference was to endorse an engineering model. Once software was engineered—like bridges or weapons systems—bugs, cost overruns, and late delivery would be a thing of the past. With 45 years hindsight, it’s easy to see that things weren’t so simple; nevertheless, the techniques promoted and developed as a result of the proclamation of the software crisis, did, in fact

1. raise the level of abstraction, 
2. increase the robustness (firmness) of the software that was written, and 
3. open the way for much larger programs to be written.

Of course, this started the same cycle of improvement followed by rising expectations all over again.



                              SPECIFIC DESIGN TECHNIQUES

Structured programming, one set of techniques popularized as a means of combating the software crisis, was designed to make software more readable and maintainable.
Because, as the DOD researchers discovered, over 75% of the cost of a software system occurs during maintenance, it made sense to concentrate efforts on techniques to reduce that effort.

1. The first of these techniques was to simplify the “flow of control” inside programs. Flow of control is simply the sequence in which program statements are executed. In early computer programs, all or most program execution was controlled by the unconditional branch—the infamous goto. Although, at the machine level, gotos were still required, by using the goto to build more abstract control structures—the loop and the selection statement—and then programming entirely in terms of those higher-level constructs, programmers were able to eliminate a whole class of common errors and thus, increased their ability to write and understand more complex programs.
2. If hiding the “actual” flow of control inside the computer was a success, the technique of hiding or limiting the access to data was an even greater success. Researchers discovered that many common software errors of the time were caused by two subroutines inadvertently modifying a piece of data that both used. The invention of local variables— and David Parnas’ ideas on data hiding, modularization, and abstract data types—were responsible for the next advance in the creation of “firm” software. Each of these was an attempt to hide more of the details of the problem and only show the relevant information.

                 Software Design Methodologies

In applying the abstraction mechanisms that were developed during the “years of crisis” to help in mastering software complexity, programmers began to follow, and encourage others to follow, software development methodologies.

A methodology is simply a prescribed way of using abstraction mechanisms.

Methodologies consist of three things:

• A process—the step-by-step activities and related deliverables that are used to model and construct software.
• A notation—a representation, often graphical, of the subsystems that make up a system and the way they interact.
• A set of heuristics—rules of thumb or figures of merit that give the designer guidance about how the artifact being built should work.

             STRUCTURED DESIGN AND OBJECT-ORIENTED DESIGN

Software design methodologies were developed to exploit the abstraction mechanisms that were introduced with better programming techniques.

• Developed in the 1970s, structured design takes the best practices of structured programming and adds a graphical notation and a development process.The primary abstraction mechanism in procedural languages is the subroutine, sometimes called a function, which operates on a piece of data.

The primary design decision in a procedural program is apportioning the work of the program among specialized subroutines. Because of this, the shape or morphology of a system developed using structured design almost always takes the form of a tree, with centralized control invested in the top or main module

Object-oriented design (OOD), in a similar manner, arose from the ideas introduced in object-oriented programming with SmallTalk and Simula.
In an OOD system, the primary abstraction mechanism is the class.

1. A class is a combination of both data and the legal operations that can be performed on that data. 
2. The data in an OOD system,rather than being passed between operations (subprograms), is hidden and protected from access by other parts of the program, by means of a principle called encapsulation. This is simply a refinement of the ideas of data hiding that began with local variables and abstract data types.
3. The flow of control in an object-oriented program is also different from that within a structured program. Instead of superior and subordinate subroutines, the action in the program occurs as objects (instances of a class) interact with each other by sending messages

One way to think about the difference between structured designs and OO designs is to think about the difference between a centralized (planned) economy and a free-market economy.

• In a planned economy, decisions about who should produce what, and about what will be sold in the marketplace, are made at the top. 
• In a free-market economy, the economy runs itself by the interaction of millions of autonomous, independent decisions.

You could say that the major difference between structured and OO systems is the degree to which intelligence (and thus flow-of-control) is vertical or horizontal.

Resources

• The classic book treating design as a scientific subject was written by the cofounder of the Computer Science program at MIT, Herbert Simon. The Sciences of the Artificial is a set of essays that make thought-provoking, if difficult, reading. Would-be designers should give a special look.
• Looking at software design from the engineering and management perspective is Frederick Brooks Jr.’s The Mythical Man Month. The best known and most widely read book on software development, MMM was recently re-released in a nth anniversary edition. If you think that a 40-year-old book on software design and development couldn’t have anything to say to you, pick up a copy and you’ll find yourself very pleasantly surprised. This is one book everyone in software design should own.
• When Terry Winograd, Stanford University Professor of Computer Science, set out to hold a conference on software design, the unexpected result was the many different perspectives of those represented. Another unexpected result was the publication of Bringing Design to Software, which gives each of those different hearings a platform. This book, which leads off with Mitch Kapor’s “A Software Design Manifesto,” provides the broadest view on software design as a user-centered activity. Each essay is interesting in
  its own right, and is supplemented by case studies of actual software products and the design issues that they illustrate.
• That's another book that attempts to reconcile the engineering and user-centered design camps in software development is Nathaniel Borenstein’s Programming As If People Mattered: Friendly Programs, Software Engineering, and Other Noble Delusions. Written as a series
  of anecdotes, this book will be especially helpful to the programmer or software engineer who wants to learn about adding “commodity” to his(her) programs. If you still can’t decide whether computer science is really a science, you’ll want to read Chapter 20, “The Ivory Tower.”