Revolutionists ,Evolutionists ,

Object-Oriented Paradigm
In the process of learning about the object-oriented paradigm and all that
it encompasses, you will first become aware of the many divisions within
our community.
Each division implies two or more camps who are generally very
religious about their point of view.
One of the first divisions of importance is the revolutionists versus the
evolutionists.
The revolutionists believe that a group of developers woke up at 3
o'clock one morning and realized that we have been developing software
the wrong way all along.
They believe they have found the solution to the software crisis, and the
name of that solution is object-oriented programming.
The evolutionists feel that object-oriented programming is no revolution
in software development.
It is simply the next logical step in a long series of steps that take the
software developer further and further away from the machine details.
 A software crisis does not come about because we are incorrectly
developing software.
 A software crisis comes about because our paradigm of programming is
no longer sufficient to handle the complexity of problems we are asked
to solve.
 Using octal and/or hexadecimal opcodes to write programs is a great
paradigm when there are only 8 instructions and 1K of memory in our
machine..
 When my hardware becomes more sophisticated I begin using assembly-
language mnemonics. This works great until a point where the
complexity of my problems outgrows this paradigm.
 I similarly upgrade to using a high-level language whose instructions
each replace many assembly-language mnemonics, allowing me to think
at a higher level.
 Aside from reducing the language complexity, I also seek out a better
way of thinking about my problem.
 Instead of stringing instructions into small functions and small functions
into programs, I use a structured method for breaking my problem into
smaller pieces, each of which is manageable.
 We are currently at a point in software development where structured,
top-down design methods are no longer sufficient for handling the
complexity of problems possible with today's hardware.
 We need to find a paradigm of software development that can handle the
added complexity. Very recently—in 1985—menu-driven systems were
the norm.
 Today, a software application must have a graphical user interface if it is
to be marketable.
 Within the next few years, the consumer will demand multimedia
applications that talk to them, listen to them, and display moving video
across the screen.
 Why is the object-oriented paradigm generating so much interest as
a method for handling these more complex applications?
 One of the biggest reasons for moving to the object-oriented
paradigm for developing complex applications is that it allows
designers more closely to model the real world.
 Structured methods are built on the idea of centralized control.
 The strength of a decentralized architecture is the fact that any one
problem will affect one area of the application, which, in a good
design, will be loosely coupled to the other areas of the application.
 This limits the impact of change on our system should there be a
problem with one application area, or should we wish to extend the
same.
 If decentralization allows the real world, with all of its
complexities, to operate, shouldn't we attempt to handle complex
software problems in the same way?
 Accidental Versus Essential Complexity
• Frederick Brooks published a very interesting article in the October
1987 issue of IEEE Computer, titled “Conceptual Essence of Software
Engineering or There Is No Silver Bullet” .
• The “No Silver Bullet” article is a follow-up on his insights for
software engineering.
• In it he discusses why we have a software crisis, why there is no magic
methodology that will cure all of our problems, and what promising
techniques we can use in the future to lessen the crisis.
• A fundamental point the article makes is that there are two types of
complexity feeding the software crisis; accidental complexity and
essential complexity.
 Accidental complexity
 Accidental complexity occurs due to a mismatch of paradigms,
methodologies, and/or tools in our application.
 This type of complexity can be eliminated given sufficient resources
to build or buy tools that complement one another.
 Object-oriented programming helps to eliminate accidental
complexity by providing a consistent paradigm for software
development that encompasses analysis, design, and implementation.
 This is not to say that object-oriented software projects do not
contain accidental complexity.
 The MIS (management information science) world and other
domains are faced with a particular type of accidental complexity.
 These groups have invested large sums of money in relational
database technology and are now moving from the action-oriented to
the object-oriented paradigm.
 Essential complexity
 The real culprit of the software crisis is essential complexity.
 Essential complexity revolves around the fact that software is
intrinsically complex, and no methodology or tool is going to
eliminate this complexity.
 There are several reasons why software possesses essential
complexity:
(i)Software applications, for their size, are the most complex
entities that humans build.
(ii)Software is intangible and, for the most part, invisible.
(iii)Software does not wear out in the traditional sense of
machinery with moving parts wearing out.
 However, software is constantly being used in ways its authors
never expected (often uncovering errors), and end users are
constantly demanding extensions to their software.
 The Waterfall Model

 The old paradigm of treating the software development process as

an assembly line is no longer valid.
 Consider the traditional waterfall model of software development
(see Figure 1.1)

Fig 1.1

In this model, analysis, design, coding, testing, and maintenance

form five discrete steps, each having a well-defined input and a well-
defined output.
At each transition the outputs become deliverables that allow managers
to assess the project's progress.
 It became apparent rather quickly that software wasn't exactly an
assembly-line process.
 Consider the best course of action on an assembly line if one link in
the chain is slowing down the rest of the assembly line.
 For example, what should we do if our assembly line is
constructing dolls and the person putting on the arms is slowing
down the line? Obviously, we should put another person on the line
to help with the arms. This will eliminate the bottleneck.
 Try this technique with software engineering, and the results are
often disastrous.
 If coding is running late, a project manager cannot simply add a few
members to the development team. The current members of the team
will see a decrease in productivity as they take the time necessary to
train the newcomers.
 Nevertheless, many companies have continued to use the waterfall
model for project development.
 The Iterative Model

 The iterative model of software development is basically a

waterfall model, except we allow software developers to move in
two directions along the flow of the project (see Figure 1.2).
 If we detect a design flaw while coding part of the application, we
can move back to the design phase and correct it.
 Or if we detect the need for a new system requirement while testing
part of the application, we can move back to the analysis phase and
repair the problem.

Fig 1.2 The Iterative Model of software development

 This model of software engineering causes many problems in the
action-oriented paradigm.
 Action-oriented software often has many hidden dependencies
between data and behavior.
 Combine that with a centralized control mechanism, and you run into a
situation where you touch an existing application and the whole world
crumbles into dust.
 The thought of adding a new requirement or changing the design when
90 percent of the application has been coded is not an option.
 The object-oriented paradigm corrects this problem by providing
its developers with a decentralized form of flow control and the
ability to prevent hidden dependencies between data and behavior.
 For these reasons, the iterative model of software development is
becoming the process of choice among object-oriented developers.
 Software prototype
 The iterative model is not without its problems, however.
 the model currently lacks a series of well-defined development
milestones.
 we need new iterative milestones that can provide the necessary
feedback without the burden of casting large portions of the
application in concrete.
 One such deliverable is known as the software prototype.
 The field of prototyping comes from the realization that complex
entities in the real world are grown and not built.
 Many developers are looking to prototyping as a method for
controlling the essential complexity of modern-day software.
 Through prototyping, an application can be grown a layer at time,
each layer being thoroughly tested before moving on to the next layer.
 In this way, design flaws can be detected early enough to facilitate
inexpensive corrections
 while the working prototype can also serve as a productivity metric.
 Same- Versus Different-Language Prototyping

 The field of prototyping is divided into two main philosophies.

 These revolve around the argument as to whether a prototype should be
written in the same language as the final product (same-language
prototyping) or a different language (different-language prototyping).
 In same-language prototyping, the advantages seem almost too good to
pass up.
 The development team need only use one language, which implies one
set of tools, one set of books, one learning curve, and one set of training.
 Ssame-language prototyping is the more common of the two types.
 The final prototype essentially becomes the product.
 The major disadvantage to this model of development is that during
prototyping, the writing of garbage code that lacks any bells/whistles,
efficiency, robustness, or extensibility is allowed, if not encouraged.
 Another issue with same-language prototyping is that language issues may
cloud a designer's judgment at a time in system development where
software platforms are not supposed to be in the forefront.
 Different-language prototyping
 In different-language prototyping, we can swap the advantages and
disadvantages discussed above.
 The overhead of two learning curves, set of tools, and so on can be
prohibitive.
 The advantage of never “accidentally” shipping garbage code
 Being able to work in a pure object-oriented environment regardless
of the application's target language,
 It has been enough to win over many companies to this philosophy
of prototyping.
 A typical language combination is SmallTalk for the prototyping
and C++ for the target language of the application .
 Software Reusability

 Another method for controlling the essential complexity is to avoid the

development of software all together
 Instead of building software, why not buy it?
 Our MIS developers do not build their relational database; they buy one. If
you need a spreadsheet, you will not build your own; you will buy it from
Lotus, Microsoft, Borland, or some other vendor.
 The advantage of buying software is that it is cheaper than building
the software, especially when maintenance costs are considered.
 The major disadvantage is that you get whatever functionality you are
given. The software you build yourself meets exactly your specifications,
while the software you buy probably does not.
 Instead of the term “buying software,” many people are now referring
to “reusing software.” The term “software reuse” has become a major
buzzword in the object-oriented community.
Why all the excitement with reusing software in the object-
oriented world?
 Why the renewed discussion on software reusability?
 As it turns out, there is an inverse proportion between the size (or
granularity) of the code we reuse and its flexibility. If statements are
very small and very flexible, while Lotus 1-2-3 is a much larger level of
reuse, but it has a specific purpose.
 It is thought that the types of constructs found in the object-oriented
paradigm find a happy medium between the granularity of the software and
its flexibility.
 Unfortunately, the level of software reuse achieved in object-oriented
applications has been disappointing for many developers.
 Corporate Hierarchies of Good Designers

 A last topic Brooks mentions in his “No Silver Bullet” article as

a method for controlling essential complexity is to create a
corporate hierarchy of great software designers.
 giving them a large pool of junior designers from which they can
groom their replacements.
 The analogy to management is provided in that senior managers sit
at the top, grooming their replacements from a broad base of junior
managers.
 This cuts to the heart of the “art versus science” argument among
software developers. Is software development something we learn or
is it a talent with which we are born?
 if someone put a gun to my head and told me I had to learn to play
the piano in one year (and I play no musical instrument), I wouldn't
be too worried. If my life depended on it, I have no doubt I can learn
to play the piano.
 If the person then told me that in three years I had to be a great
concert pianist, I'd be a dead man!
 Regardless of whether great designers are born or built, I think there is a
serious flaw in creating a hierarchy of great designers.
 It is the same flaw that we find in some of corporate management today.
From what sources do new ideas generally come?
 New ideas are traditionally the product of grass-roots movements starting
at the lowest levels.
 By creating hierarchies, we risk stagnation.
 I believe the reluctance to offer object-oriented programming to
undergraduates in academia stemmed from a hierarchy of people who
have preached the merits of action-oriented development.
 We are now entering an era where software development has become too
complex for structured methodologies to handle.
 The future only promises additional complexity as hardware evolves at its
exponential pace.
The question is, can we produce a software development methodology that offers a
chance to eliminate accidental complexity and, at least, control essential complexity ?
 The object-oriented paradigm, with its
i. decentralized control flow,
ii. bidirectionally related data and behavior,
iii. implicit case analysis (i.e., polymorphism),
iv. information-hiding mechanisms, coupled with
v. rapid prototyping and
vi. an iterative model of software development,
offer the best chance for achieving this goal
 Glossary of Terms
 Accidental complexity
The complexity in an application resulting from the use of mismatched tools
or paradigms of software development.
 Different-language prototyping
A philosophy of prototyping in which the language used for the prototype is
different from the language used for the application.
 Essential complexity
The complexity of an application due to the intrinsic qualities of the software
itself.
 Multiparadigm language
A programming language that supports both the object-oriented and action-
oriented paradigms.
 Paradigm shift
The movement toward a new model of programming from an older model.
 Programming paradigm
A model of developing software.
 Pure object-oriented language
A programming language that supports only the object-oriented paradigm.
 Same-language prototyping
A philosophy of prototyping in which the language used for the prototype is
the same as the language used for the end product.
 Software prototype
A model of an application built to test the feasibility of a software design,
implementation, or solution. It often omits features of extensibility,
efficiency, and robustness in favor of a speedy implementation.
 Software prototyping
The act of producing an example of an end-product application in order to test
or prove the feasibility of a particular software design, implementation, or
solution.
 Iterative model (of software development)
A flexible model of designing software which recognizes that software
development is an iterative process that must allow its practitioners the
ability to modify existing results in order to fix earlier mistakes.
 Waterfall model (of software development)
A rigid model of designing software which focuses on milestones with well-
defined deliverables. The development process is one-way, i.e., once a
milestone is reached, earlier process steps cannot be revisited.