1. About this course

Part of CS:2820 Object Oriented Software Development Notes, Fall 2015
by Douglas W. Jones
THE UNIVERSITY OF IOWA Department of Computer Science

 

Prerequisites:

This course assumes two semesters of prior programming coursework in a programming language such as Java, Python, C++ or other languages. If your experience is in older languages such as C, or Pascal, you will have some difficulty, and if your experience is largely in BASIC, COBOL, or FORTRAN, you will really need to work hard.

From the first programming course, you should have learned the basics of programming. How to write programs involving loops, if-then-else constructs, and function calls. You should be comfortable with simple variables, arrays and perhaps the outside view of several container classes.

From the second programming course, you should have learned something about data structures and algorithms. Lists, queues, binary search, lexicographic trees, sorting, and several recursive algorithms. The formal analysis of algorithms is a more advanced topic, but you should have seen enough to develop an intuition for the fact that some algorithms are potentially much faster than others when used to achieve the same goal. Consider for example the difference between binary search and linear search, or the difference between quicksort and bubble sort.

In general, programming assignments in these courses are short, rarely amounting to more than a few hundred lines of code, and frequently under 50 lines of code. (Yes, the "line of code" is a horrible way to measure program size, since any program can be converted, with very little effort, into a program that is twice the size.)

Goals:

Previous offerings of this course have used several different languages, but what matters is, this is not a course about a specific programming language. You know how to program, and learning the syntax of a new language is not all that hard.

It is noteworthy that the programming languages you are likely to have learned in any intro course taught in the last 20 years all support object oriented development, but the small programming assignments you had in your intro courses are unlikely to do more than use built-in classes, and in a second semester course, while you may have implemented a new class, you didn't really need to do so except that it was assigned. This is a natural consequence of small programming assignments.

The need for something like object oriented programming is not apparent until you get into large problems. Try to write a digital logic simulator capable of simulating a complete CPU at the level of and, or and not gates. Try to write a compiler, try to write a spreadsheet package, or any of many other large applications, and you will find that the story is quite different. If object oriented programming had not been developed already, you would be very likely to re-invent it.

This course, therefore asks you to work through a large programming project, large enough that you really need to use objects. Programming in the large will ask for more than objects, it also requires management, documentation and methodology.

When you write small programs, who needs documentation? Here is an example, written in the old C programming language. The fact that you don't know C should not matter to your understanding of this code:

	int add( int a, int b ) {
		return a + b;
	}

Not knowing C, you may need someone to explain that int is a data type and that declarations in C put the type name before the object being declared, but with this, you should be able to guess that the function call add(1,2) will return 3. Adding comments or writing a page of documentation to this code serves no useful purpose.

The story is quite different when your program is 5000 lines long. At that point, you can't grasp the whole thing at a glance, and you are unlikely to be able to remember from one day to the next what each part of the program does. When programs get that big, you need documentation even if there is only one programmer, and when there is a team involved, it is even more important.

In summary, this is a course about programming in the large, where up to this point, you have been programming in the small.

Software Engineering:

The term software engineering has frequently been used for what this course introduces, but this term is simultaneously falling on hard times in some circles while it becomes deeply entrenched in others.

Knowing something of the history of software engineering helps understand the conflict here. As software systems grew in the 1960's and 1970's, people looking at the economics of software noticed something disturbing: While the price of hardware was falling, following Moore's Law, the cost of software was soaring. This came to be known as the "software crisis" and it never ended. There were huge software boondoggles in both government and private industry. F. P. Brooks' book The Mythical Man Month documented the problem and proposed some solutions.

Many observers of this situation found the contrast between the productivity of hardware engineering and the crisis with software development asked: "Why can't software development be done as an engineering discipline." This led naturally to the term "software engineering" as a buzzword for how software ought to be developed.

The negative assessment of software engineering rests on two observations: First, many of the early proponents of software engineering seem to have had romantic misunderstandings of the nature of engineering. If you ask the designers of a bridge across a large river what they are doing, they will typically describe the initial stages of the design as being high art. Selecting between a cable-stayed bridge and an arch bridge, for example. And then, a typical civil engineer would say, "and then the real engineering begins, deciding how much rebar to put where, how many bolts go in this joint, how thick is that cable?" The work the civil engineer describes as "real engineering" is comparable to the detail work in computing that people sometimes call "coding".

Meanwhile, the work that proponents of software engineering want to call engineering and want to systematize seems comparable to the high level design work that civil engineers might refer to as being a high art.

Second, the industrial response to the emergence of the term "software engineering" was the immediate promotion of this term to a job title. This allowed parallel pay and promotion structures programmers and conventional engineers without offending personnell managers.

Now, 35 years after the emergence of software engineering, there are skeptics in both the academic and industrial world who consider software engineering to be, at best "computer science lite" (to quote one former department chair).

Meanwhile the study of software engineering has produced insights into the management of large projects. Some things that sound like buzzwords that have come from software engineering are actually valueable. "Extreme programming" is an example. While slavish adherence to the XP methodology may be silly, the underlying ideas of incremental development are very powerful. UML, as a formal graphical language for describing programs may be foolish, but selective informal use of the notation is frequently useful during the early stages of a software project.

Origins of Object Oriented Programming:

The idea of object-oriented programming was born in two different domains, independently and around the same time in the mid 1960s:

A group of programmers working on discrete-event simulation Oslo, Norway developed the idea of objects, classes, class hierarchy and almost all of the other key concepts of object-oriented programming in the mid 1960's. They came at this from thinking about discrete event simulations, mostly as applied to logistics. If you are moving materials from here to there, you have trucks to move things, but there are different classes of trucks each with different attributes. Semi trucks and pickup trucks are both types of trucks, but you can detatch the trailer from a semi, while you cannot detatch the cargo area of a pickup (ignoring the possible use of a chainsaw on a modern aluminum truck).

This group, led by O.J. Dahl, developed a simulation language called Simula while they were working this out, and as they finally came to understand the consequences of their ideas, they created a distinctly new language called Simula 67 (the target release date was 1967, but since this is software, they were late).

Simula 67 was not a simulation language, it was a completely general purpose object-oriented programming language, the very first of its kind. We get essentially all of our standard terms for object-oriented programming from Simula. Some people have described Simula 67 as an improvement over most of its successors.

The other important group in this story was a group led by Christopher Strachey at Cambridge University in England. Strachey was as much a theorist as a practical programmer. His group designed a programming language called CPL (there is disagreement about whether the C stood for Christopher's or Cambridge or Combined, but PL stood for Programming Language). Nobody ever succeeded in implementing CPL, but a student implemented a subset called BCPL (Basic CPL).

One of the things that Strachey's group explored was the use of BCPL as an operating system development language. It is important to know that BCPL was not object oriented in any way. It was very primitive, but unlike other languages of the era (with the exception of assembly language), it allowed people to invent just about any kind of programming model they wanted. As Strachey and his associate Joseph Stoy developed a toy operating system called OS6, they discovered the basic ideas of objects, applying them primarily to I/O streams, where all kinds of I/O were implemented essentially as subclasses of a common stream interface class. They did not have object-oriented terminology, but they had the idea.

A group at Bell Labs in Murray Hill, New Jersey seti out to build a new operating system in the late 1960s. They called it Unix, and they were quite interested in BCPL, enough so that they built a new implementation for it that they named, simply, B. The B project and the first version of UNIX were married when they wrote a new compiler that (naturally) they called C and used it to rewrite UNIX. The internals of Unix, particularly, those involved with input/output, have a strong object-oriented flavor despite the fact that there is no support for objects in C.

When Bjarne Stroustrup, an experienced Simula 67 programmer, was hired by the Unix group at Bell Labs, he was sufficiently annoyed by the lack of support for objects in C that he wrote a C preprocessor that he called C++ that extended C with the features of Simula 67 that he liked. Originally, this was just his way of producing code in C (policy required that) without having to write in a language he considered inadequate.

By 1980, C++ began its spread outside of Bell Labs and the Unix world. Two things contributed to this: One was BSD Unix, the first version of Unix supported on the then best-selling 32-bit mainframe of the era, the VAX 11/780 made by Digital Equipment Corporation. We bought one here at the University of Iowa, and we ran Unix on it, and the story was very sinilar around the world. The second thing was the GNU C++ compiler, the most important of the early ventures in open-source software development.

At Sun Microsystems in the early 1990s, James gosling was not happy with the C foundation of C++ and set out to strip away the mistakes that C++ had inherited from C and produce a lightweight language called Java. This had two main selling points: First, it looked like C++ so programmers who knew that language could move to Java with minimal "culture shock." Second, many of the dangerous features of C were disabled. Some early wags described Java as being C++ with training wheels.

A Public Service Announcement:

There are two career fairs early in the Fall semester that really matter to CS students: The Business and Liberal Arts Career Fair and the Engineering Career Fair. CS students are welcome at both career fairs

Many of the employers coming to these fairs are looking for co-op internships and they expect to fill all of their internships for next summer with students they interview at the fall career fairs. In past years, Amazon, Apple, Hewlett Packard, Intel, Microsoft and other firms have followed this model.

In the past, students from the University of Iowa have done very well at these companies, but to compete in this arena, you must have your résumé ready before the fair. That means starting now!