CS320 Lecture: Course Introduction. 7/22/96 - revised 8/3/99
Materials:
1. Syllabus
2. Transparencies: Dale/Weems (4th ed) p. 115
Booch fig 9-11 p. 311
Booch fig A-1 p. 473
I. Introduction
- ------------
A. Roll
B. Syllabus
II. Software Development Paradigms
-- -------- ----------- ---------
A. The title of this course is "Object Oriented Software Development with
C++". It is critical that we understand from the outset that there are
two foci of the course, and that of the two one is by far the most
important.
1. The minor focus of the course is the C++ programming language.
2. The major focus of the course is on learning a new software
development paradigm called object orientation.
B. Object orientation is fundamentally a new PARADIGM - or way of thinking
about problems and their solutions. If this course is successful, you
will emerge from it with a new way of THINKING - a new way of analyzing
problems and developing solutions to them. (If you emerge from this
course having only learned a new programming language, then regardless
of what grade you get this course will have been a failure.)
C. Since we are talking about learning a new paradigm, we perhaps ought to
begin by talking for a bit about the notion of software development
paradigms.
1. The earliest software development paradigm was a very MACHINE-ORIENTED
paradigm.
a. Programming was done in machine language or assembly language.
b. Problems that were attempted were of limited size, user interfaces
were minimal, and effiency (time and space) was a major concern (if
not the dominant concern) because storage capacity and
computational speed were very limited.
c. Software was highly dependent on the specifics of the particular
machine it was to run on.
As as a result, the software developer spent a lot of time thinking
about the MACHINE, rather than the PROBLEM.
Example: preoccupation with minimizing the size of a program, leading
to various forms of "bit-twiddling" such as using a machine
instruction as a constant if value happened to be right.
2. The paradigm you are most familiar with is called the STRUCTURED or
PROCEDURAL paradigm.
a. The shift to this paradigm began with the introduction of higher
level languages, which, coupled with growing capabilities of
computers, allowed software developers to shift more and more
of their attention away from the machine and onto the problem, and
allowed the development of portable software that could run on more
than one model of computer.
b. However, early HLL programmers still developed software with a very
machine oriented control flow - i.e. in early HLL's the goto
statement was still the major control structure. The need for a
new paradigm became evident as this approach broke down in the
face of rapid growth in the size of software systems.
c. The major shift to the structured or procedural paradigm occurred
during the 1970's. One sign of this paradigm shift was the
appearance of numerous articles and books with titles that contained
phrases like "structured programming" and "structured design".
Example: In the early 1980's textbooks I used for introductory
courses tended to have titles like "Structured Basic" or
"Structured COBOL".
Example: A major reason why Pascal became the "lingua franca" of
Computer Science in the 1980's was that the language
itself was designed around the assumption that programs
would be developed using the structured paradigm.
d. At the heart of this paradigm is the idea that a piece of software
is constructed as a hierarchy of procedures, using step-wise
refinement and top-down design.
Example: The following transparency - taken from the Dale/Weems
CS121 book - exemplifies this approach to software
design:
TRANSPARENCY - DALE/WEEMS P. 115
3. As the procedural paradigm developed, it became apparent that more
attention needed to be paid to data structures, along with algorithms.
a. Example: an early and important book by Niklaus Wirth - the inventor
of Pascal: "Algorithms + Data Structures = Programs" (1976). Wirth
went on to embody these ideas in a new family of languages -
intended as successors to Pascal - called Modula, Modula II, etc.
b. Example: in the 1980's there developed a fairly broad acceptance
in the CS education community that a standard introductory
sequence would consist of a course teaching the procedural
paradigm (like our CS121) followed by a data structures oriented
course (like our CS122)
c. To the procedural paradigm, then, was added the concept of an
ABSTRACT DATA TYPE (ADT). This is probably best considered an
augmentation of the procedural paradigm, rather than a wholly
new paradigm, though.
4. Concurrent with the development of the procedural/ADT paradigm, a
different line of development was leading to the new paradigm we
now know as OO.
a. In 1967, work in Sweden led to the development of a language
called Simula for doing work in discrete simulations - a problem
domain for which the procedural paradigm is ill-suited.
b. In the 1970's, designers at Xerox PARC developed a family of
languages known as Smalltalk (Smalltalk 72, 74, 76, 78, and 80).
These languages were the software element of the Dynabook
project led by Alan Kay. It was out of this project that the idea
of a graphical user interface (GUI) emerged, and Kay went on to
play a key role in the development of the Macintosh family at
Apple - the first commercially-successful embodiment of GUI).
c. There continues to be a strong connection between OO and GUI.
i. GUI applications do not lend themselves well to the procedural
paradigm.
- What does the main program of a GUI application do?
- In a real sense, the user of a GUI application really plays the
role played by the main program in more traditional
applications, and the main program as such is actually an
"event loop" that waits for the user to take some action and
then sends it off to some component that knows how to handle
the particular request.
ii. As we shall see, the OO paradigm provides a much more natural
way for developing GUI's. For this reason, most GUI applications
are developed using OO technology - at least for the user
interface.
Example: Apple developed a variant of Pascal known as Object
Pascal as the standard language for developing Macintosh
applications. Today, C++ is largely used for this
purpose, both in the Macintosh and Windows worlds.
iii. The reverse is not necessarily the case, though - OO applications
can be built using any kind of interface, not just GUI.
d. As I said earlier (and will say again and again) OO is not just a
different programming language - but an altogether way of looking
at problems. An OO system is NOT a hierarchy of procedures that
work together in top-down fashion - it is a collection of objects
that work together as peers.
Example: The following is an example of a high-level design for an
OO application. (Contrast with the previous transparency)
TRANSPARENCY - BOOCH FIG. 9-11
(More on this later)
5. As an aside, we should note that OO is not the only alternative to
the procedural paradigm to have arisen in the past 20 years. New
paradigms often arise to address classes of problems which don't
match the current conventional paradigm well (as was the case with OO
and discrete simulation and later GUI's) We will look at a couple of
other paradigms in the Programming Languages course:
a. The FUNCTIONAL PARADIGM - exemplified by APL and LISP
b. The LOGIC PARADIGM - exemplified by Prolog
6. What makes the OO paradigm special is that it has moved out of the
realm of being a tool for solving certain categories of problems and
into the realm of being a general purpose paradigm that competes with
the procedural paradigm. One interesting question to consider is the
ultimate relationship between the OO and procedural paradigms.
a. Will OO eventually replace the procedural paradigm for most
purposes?
i. Many OO proponents say yes
ii. Currently a subject of debate in CS education circles - should we
teach both paradigms (as Gordon has been doing) or start with OO
in the intro courses (as we are doing with freshmen this year)?
b. Or will OO and procedural exist side by side, each being applied in
appropriate problem domains?
c. Probably too early to tell for sure, but (a) seems ultimately
likely. The question of time frame is a large one, though.
III. Wny a New Paradigm?
--- --- - --- ---------
A. The talk of OO as a new paradigm that may be in the process of replacing
the current paradigm raises an important question: why do we need a new
paradigm?
B. As you recall, in CS122 we talked about the "Software crisis" - the
realization that began to emerge almost 30 years ago that hardware
capabilities have been developing at a faster rate than our ability to
produce reliable software to take advantage of these capabilities.
1. The RAM and disk capacities of a "standard" PC continue to grow at a
geometric rate, as have CPU speeds.
Example: The Mac I got in 1990 came with: 1 MB/40 MB/16 Mhz
The Mac I got in 1995 came with: 8 MB/250 MB/66 Mhz
The iMac I got in 1999 came with: 96MB/6 Gig/333 MHz
2. With this growing capacity and speed has come a user expectation for
much larger and more sophisticated software packages to take advantage
of these capabilities, using graphical user interfaces, WYSIWIG
editing, etc. As a result today's software packages may be an order of
magnitude larger than software packages sold to do a similar job not
too many years ago.
3. Of course, more effort is involved in developing such packages - in
fact, the development effort goes up faster than program size.
(Effort as a function of size is more than O(n)).
4. Alongside of new software development has also come the need to
update and maintain an existing installed base of software that
cannot be simply scrapped and replaced.
5. The key elements of the procedural paradigm (including ADT's) were,
in fact, developed to help meet this crisis, and contributed to
whatever successes software engineering has had in scaling up to
ever more powerful platforms. However, as software complexity
continues to grow, the need for a better paradigm has begun to
become evident.
B. Object-Oriented Design and Programming is a more recent approach to
addressing issue related to software complexity, It is certainly not a
panacea, but it has been getting a lot of attention in the 1990's as one
very helpful tool for addressing the software crisis. OO approaches
target two key issues:
1. Improving software modularity. This facilitates:
a. Involvement of many individuals in one project, without getting in
each other's way.
b. Testing of pieces of an overall system. (Unit testing).
c. Software maintenance. The goal is to isolate changes that need to
be made during maintenance to a single module, rather than having
them impact the entire system.
2. Software re-use through development of software components.
a. In most engineering disciplines, designers have available a large
base of standardized components from which to construct products
as needed.
i. An electrical engineer has standard discrete components and
chips available "off the shelf" from vendors.
ii. A mechanical engineer has standard components like fasteners
(bolts, nuts), etc.
iii. A civil engineer has girders and standardized designs for
different sorts of bridges, etc.
b. Much software development work, however, is still done "from
scratch". This would be like requiring a mechanical engineer to
custom design all the screws used in building a product!
3. The reason why OO helps in these areas can be seen by contrasting
the two design approach transparencies we looked at earlier.
SHOW TWO TRANSPARENCIES AGAIN
a. In a procedural design, the top-level module embodies the high
level functionality of the specific application, and each other
module is designed as part of the process of refining the one
above it.
i. Thus, maintenance changes to a module often affect the entire
subtree rooted at that module.
ii. Further, application-specific characteristics tend to work their
way down the hierarchy, making it hard for a module developed
for one application to be re-usable for a different application,
at least without significant reworking.
b. In an OO design, each object (or class of objects, as we shall
see) tends to be relatively independent of most other classes.
i. Maintenance changes tend to focus on one class or a cluster of
closely-related classes, and have little impact elsewhere.
ii. Re-usability is enhanced.
iii. If a new feature is needed, it can often be added by adding a
new kind of object to the system, with little or no changes
needed to existing objects.
C. There have been a plethora of object-oriented tools introduced in recent
years.
1. Object-oriented analysis and design methodologies.
These are referred to, respectively, as OOA and OOD methodologies.
(We should note that the line between the two is somewhat blurry).
2. New object-oriented programming languages, and extensions to
existing languages.
Use of OO techniques in programming is referred to by the generic term
OOP.
NOTE OOA, OOD, AND OOP IN SYLLABUS
3. Object-oriented databases etc.
This is a somewhat newer area, and is not something we will talk
about in this course (though we do say something about it in the
database course). These are referred to as OODB.
D. We will be getting our introduction to the world of object-orientation
by way of a specific object-oriented programming language: C++ - which
was developed by Bjarne Stroustrup of AT&T Bell labs with a view to
producing an object-oriented version of C. It is important to remember,
though, that object-orientation is much bigger than just a specific
programming language, or even programming itself. It is a mindset that
permeates the entire software development process from initial design
through ongoing maintenance.
1. It turns out that there is often a strong connection between
programming languages and software development paradigms.
Frequently, new languages are developed to support new paradigms, or
evolutionary changes in existing paradigms.
2. C++ is one of many programming languages that reflect the development
of the OO paradigm. Technically, such languages fall into three
categories:
a. Object based languages - support some of the OO paradigm, but not
all of it.
b. Object oriented languages - support the OO paradigm fully. Many
are hybrid in that they also support the procedural paradigm.
c. Pure object oriented languages (POOP) - force the use of the OO
paradigm
TRANSPARENCY - BOOCH FIG. A-1
Note: The transparency classifies Ada as Object-based, not OO. This
is true of the original Ada (Ada 83), but not the most recent
version (Ada 95). Also, the transparency predates the rise of
Java, which is also a pure OO language.
3. At the NSF workshop on teaching OO I attended, one of the topics of
conversation was the question of what language to use in teaching OO.
A case was made for using a pure OO language like Smalltalk, because
of the danger that use of a hybrid language would tempt people to
stick with the more familiar paradigm. We have chosen C++ for this
course because of its wide use in industry; but you need to be wary
of this danger as a result! (We are using Java in the intro sequence)
Copyright ©1999 - Russell C. Bjork