Computer Science 272 Software II

Dr. Stephen Bloch office 112 Alumnæ Hall phone 877-4483

                email sbloch@boethius.adelphi.edu

office hours ???

January 20, 1996

1 Subject Matter

This course, in a few words, is about how to organize a computer program. The skill of organizing a computer program well has several benefits. First, you’ll understand your own program better if it’s organized in a way that “makes sense”. Second, you can find and repair bugs, and make enhancements, in your program more easily if it’s organized in a way that makes it easy to modify. Third, other programmers can read, understand, repair, and enhance your program more easily if it’s organized according to these same principles.

Up to this point in your computer science career, you’ve typically been given a programming assignment, written it by yourself, turned it in, and gone on to the next assignment. This is not what happens in the real world! In the real world, most computer programmers spend most of their time, not writing new programs, but debugging and modifying old ones, including old programs written by other people. This places an additional burden on both programmers: the new programmer must be able to understand and modify somebody else’s program, and the original programmer must write in a way that can be understood and modified easily.

The programs you’ve written up to this point are typically a few dozen lines long. In the real world, most programs are thousands, perhaps even millions, of lines long. You may be able to write a twenty-line program without planning, keeping the whole thing in your mind at once. But that seat-of-the-pants approach doesn’t work for large programs. No human being can keep a thousand-line program in mind all at once without organizing and breaking down the program into manageably small, coherent pieces.

The course will start with some of the most basic techniques for program readability: naming, indentation and white space, symbolic constants and enumerated types, comments, and factoring out duplicate code. We’ll go on to the more advanced techniques needed for problems of realistic size: abstraction, encapsulation, information-hiding, and modularity.

In particular, we’ll discuss a strategy, currently very fashionable in computer-programming circles, called “Object Oriented Programming”, or OOP. To get a first impression of OOP, compare the programs you’ve written so far to English sentences. Each statement performs a particular action, corresponding to an English verb, and your main interest is what actions are performed in what order. In the English analogy, you’re concentrating on verbs. The OOP approach can be thought of as concentrating on nouns instead: rather than thinking primarily about a sequence of actions, we think primarily about a collection of objects, the properties of each, and what can be done with each one. The experience of many professional programmers shows that this approach usually works better for organizing large programs.

OOP usually requires that the programming language contain special object-oriented features. Object-oriented languages are often invented by adding such features to an existing language: for example, the object-oriented language C++ looks like C with some extra features, while CLOS (an acronym for “Common Lisp Object System”) is, as its name implies, a collection of object-oriented features added to Lisp. (We’ll actually use Scheme, rather than its ancestor Lisp, extended with CLOS features.) However, C++ and CLOS differ not only in their base language, but in their whole philosophy of object-oriented programming. Each provides support for certain kinds of object-oriented programming that would be unthinkable in the other. Each approach has advantages and disadvantages, and by the end of the semester you should be able to decide which approach is more suitable to any given programming task.

2 Prerequisites

I assume that everyone in the class is already familiar with the C and Scheme languages, and capable of writing small, working programs in either one. I also assume you can use the Unix utilities gdb, make, rcs, lex, and a text editor such as vi or emacs. (These are for your benefit, not mine: I sha’n’t grade your use of Unix utilities, but I doubt you can survive the course without using them.)

The official prerequisites for the course are CSC 270 (Survey of Programming Languages) and CSC 271 (Software I).

3 Texts

I haven’t found a good introductory textbook on readability, OOP, or object Scheme, so the first part of the course will be mostly on-line reading assignments and lectures. The optional textbook Object-oriented Analysis and Design, by Grady Booch, explains the principles of OOP very well, but it’s expensive and may be difficult reading.

After the midterm exam, we’ll switch from object Scheme to C++. The definitive book on C++ is The C++ Programming Language, by Bjarne Stroustrup, who invented the C++ language. Somewhat easier for the beginner to understand is C++ Primer, by Stanley Lippman. Since we’ll use the GNU C++ compiler, we also have extensive documentation available through the info gcc command.

I expect you to read chapters 0–3 and Appendix C of the Lippman book sometime during the first half of the course. Much of this material will be easy reading if you’re already comfortable with C. After the midterm, you’ll read chapters 5,6,8,9, and 10, interspersed with lectures on the same subjects.

You are responsible for everything in the reading assignments, whether or not I discuss it in a lecture.

4 Grading

As I write this (a week before classes start), I envision five or six homework assignments, each worth perhaps 10% of the semester grade, a midterm worth 20%, and a final exam worth 30%. Past experience suggests, however, that we’ll get behind schedule and will actually do fewer assignments than this. I’ll try to keep an up-to-date schedule on my Web page.

Exams must be taken at the scheduled time, unless arranged in advance or prevented by a documented medical or family emergency. If you have three or more exams scheduled on the same date, or a religious holiday that conflicts with an exam or assignment due date, please notify me in writing within the first two weeks of the semester in order to receive due consideration. Exams not taken without one of the above excuses will be recorded with a grade of 0.

Homework and programming assignments will be accepted late, with a penalty of 1/5 per 24 hours or portion thereof after they’re due. An hour late is 20% off, 25 hours late is 40% off, etc. No matter how late you are, however, it’s better (both for your education and for your grade) to do the assignment than not to do it at all.

Programs are not abstract works of art, they are supposed to run and solve real problems. So if I get a program that doesn’t compile or run, or a program that has little or nothing to do with the problem I assigned, I will give it a zero, no matter how much time you put into it. Don’t bother turning in a program you haven’t tested yourself.

5 Ethics

Most of the assignments in this class are to be done individually. You may discuss general approaches to a problem with classmates, but you may not copy large pieces of programs or homework solutions. If you do, all the students involved will be penalized.

However, programming in the Real World is often done in teams, so I may give an assignment or two to be done in teams. I’ll make clear which assignments these are, and who is on your team, at the time I give the assignment.

All work on an exam must be entirely the work of the one person whose name is at the top of the page. If I have evidence that one student copied from another on an exam, both students will be penalized; see above.

6 Schedule

This class meets every Monday, Wednesday, and Friday from 11:00 AM to 11:50 AM, except on University holidays or if I cancel class. All dates in the following schedule are tentative, except those fixed by the University; if some topic listed here as taking one lecture in fact takes two lectures to cover adequately, or vice versa, the schedule will shift.

Note that the reading assignments for the first half of the course have little or nothing to do with the corresponding lectures. Feel free to organize your time differently, so long as you finish chapters 0–3 and Appendix C before we start on C++.

I expect you to have read the reading assignments before the lecture that deals with that topic; this way I can concentrate my time on answering questions and clarifying subtle or difficult points in the textbook, rather than on reading the textbook to you, which will bore both of us. Please read ahead!

Date(s) Assignment Reading Lecture Subject 22 Jan Administrivia, “what is software engineering?”

24 Jan  chap. 0  Typographic techniques for readability
26 Jan  HW1  1–1.3  Constants, enumerated types, and defined types
29 Jan  1.4–1.6  Avoiding duplicate code
31 Jan  1.7,1.9  “Chunking” with modules and functions
2 Feb  HW2  1.8  Abstraction and information-hiding

Last day to add courses

5 Feb HW1 due Appendix C Objects vs. sequence

7 Feb  2–2.4  Data stored in objects; CLOS slots
9 Feb  2.5–2.8  Classes and subclasses in CLOS
12 Feb  HW2 due 2.9–2.10  Operations on objects; run-time polymorphism
14 Feb  HW3  2.11  Programming with CLOS generics and methods

16 Feb 2.12–2.14 How to design an object-oriented program

Last day to drop courses

19 Feb 2.15–2.16 Entities and Relationships 21 Feb 2.17–2.21 Kinds of Hierarchies

23 Feb  3–3.4  Interfaces and Implementations
26 Feb  3.5–3.6  Top-down, Bottom-up, etc.
28 Feb  3.7–3.8  Discuss HW3; catch up
1 Mar  3.9–3.10  Discuss HW3; catch up
4 Mar  HW3 due 3.11  Catch up, review for midterm

6 Mar Midterm exam 8 Mar Centennial Symposium; no classes

11 Mar  5–5.1  Objects in C++: aggregating data
13 Mar  5.2–5.3  Objects in C++: class member functions
15 Mar  5.4–5.5  Writing member functions

18–22 Mar Spring vacation; no classes

25 Mar  HW4  5.6  OO design of a Scheme interpreter
27 Mar  5.8  OO design of a Scheme interpreter

29 Mar  5.9  Unions (and Lex?)

Last day to withdraw from courses

1 Apr 6–6.1 Constructors and destructors

(April Fool’s Day)

3 Apr HW5 6.2 More on writing member functions 5 Apr Good Friday; no classes

8 Apr  HW4 due 8–8.2  Inheritance in C++
10 Apr  8.3–8.4  Interfaces and Implementations in C++
12 Apr  9–9.1  Polymorphism in C++
15 Apr  9.2  Complications with multiple inheritance
17 Apr  10–10.1  More on OO design of large programs
19 Apr  HW6  10.2  And yet more

22–24 Apr I’m going to a conference; I’ll

either cancel or get a substitute

26 Apr HW5 due 10.3 Catch up; discuss interpreter 29 Apr Catch up; discuss interpreter 1 May Catch up; discuss interpreter

(May Day)

3 May Catch up; discuss interpreter 6 May Catch up; discuss interpreter 10 May HW6 due Review for final exam 17 May 10:30–12:30, Final Exam