Submission to
ECOOP '99 Workshop
Introducing OO Design and Programming with Special Emphasis on Concrete Examples
Joseph Bergin
Pace University
The Courses: CS1 and CS2
Preliminary Knowledge expected: None
Lecture time: 3 or 4 hours/week for 15 weeks in each course. No closed labs assumed
Learning and practice time at home: 6-10 hours per week
Topics of the courses
(a) Introduction to Computer Science and Programming
This course is a breadth first introduction to CS, in which students program extensively using OO techniques. They are taught to read and write computer programs in a modern OO language, such as Java. Students learn the basic OO decomposition methodologies as well as lower level concepts such as looping. The instructor will need to use a variety of pedagogical patterns (http://www-lifia.info.unlp.edu.ar/ppp and http://csis.pace.edu/~bergin/) to achieve all that must be done. Elementary design patterns (http://www.cs.uni.edu/~wallingf/patterns/elementary ) intended for novices will be one of the key elements of the course.
Objects and their properties are introduced immediately with suitable mental models and analogies so that students form a sound and complete model of objects and their interactions. Object design and classes follow soon after. Functions are introduced only as ways to implement object behavior.
(b) Data Centered Problem Solving
This is an updated data structured course that teaches object-oriented data structures, reinforces design, and uses standard libraries for much of the work. Standard implementation techniques (dense, linked, …) are taught as will as the elements of algorithm efficiency.
Materials given to students:
This is currently problematical as there are few materials, especially textbooks, meeting the above criteria. The instructor will be required to develop many examples and libraries for student use. There are a number of manuscripts now in preparation that can address some of this. The site http://csis.pace.edu/~bergin has many examples of student materials. An outline of a C++ text can be found at: http://csis.pace.edu/~bergin/objectcs/ObjectCS.html , The Karel++ materials (http://csis.pace.edu/~bergin/karel.html ) can be used effectively at the beginning of the first course to give an overview.
Concrete Exercise
See Mancala in http://csis.pace.edu/~bergin/patterns/design.html This short paper also has ideas (patterns actually) about how to teach simple OO design (Find the Nouns, Model the World…)
Another good example is to have the students design a simple Relational Database System, by documenting the objects and classes that will be needed. This is part of the breadth component of the course and the design will not be implemented here.
Games, generally, are a good source of design problems as the students find the rules easy to grasp or already know them, and the rules give a good statement of the work to be accomplished without leaving the project too open-ended. One chapter of the C++ manuscript mentioned above is a set of ideas for such projects.
Solution (Not presented: There are too many possibilities, both for the work to be done and for the solution. Each should be evaluated individually and several designs should be compared for tradeoffs. See Student Design Sprint, mentioned below.)
How much Structured Programming should be taught before the first OO course? NONE (emphatically). If an earlier course is needed, then it is strongly suggested that it use the functional paradigm and not the procedural/structured paradigm.
How much design should we teach in the first year? Design should pervade these two courses. It should be both subtle and explicit. The instructor must invariably use good designs and must show only good designs. Some readings will have good design implicit in the code, which can be given before the design is revealed. A bit later, designs can be given early to motivate a program given for reading and extension. From that point, designs can be developed (in class and in labs) for student implementation in programs. Design patterns must be used and must form the basis of many of the programs shown to students. At some point in the course, they may be introduced specifically, though they are not one of the actual course topics.
The pedagogical pattern Student Design Sprint can be used after a quick introduction to CRC cards and/or object diagrams. Alaistair Cockburn has a wonderful exercise for students designing a coffee machine in about three or four cycles in which the
requirements become more sophisticated each cycle.
(See http://csis.pace.edu/~bergin/fivepedpat.html )
What OO concepts should be introduced and in what order?
Objects are primary and are introduced immediately. Objects and their properties are discussed using problems that require more than one kind of object. Object interactions are the primary focus, though composition can be discussed as well. Classes follow as a focus of design. Low level details of implementation are delayed, with loops coming quite late. A tremendous amount of computer science and programming can be taught without loops if objects and simple if statements are available.
What environment should we use? Students need access to a simple design tool that implements some small subset of UML so that their designs may be directly represented. A student of this author is currently developing such a tool in Java.
How do we teach user interface design? As with much of what must be done in these courses, many complete examples must be given to aid student reading and understanding. Design patterns (e.g. Java Event Patterns) must also be employed to efficiently teach the students best practice. Students learn through emulating good designs and in reflecting on design patterns. (see http://sol.pace.edu/java/gui for a simple tutorial in Java. These implement the Java Event patterns found at: http://csis.pace.edu/~bergin/patterns/index.html )
What kinds of problems do we teach? The courses should cover much of the material of computer science in a simple way. At the end of these two courses a student should be able to make an informed decision as to their continuation in the field. This implies that they have seen programming and design from a wide variety of the sub fields of CS/IS. Students will need to work on larger programs than has been typical in the past. This, in turn, implies that they will work in teams and on parts of larger programs for which they do not provide the complete solution. Design documents can help guide their understanding here of what must be done. For example, a complete design can be given and a partial implementation, with instructions to complete (or repair) the implementation. Complete designs can be extended in small ways by novices. Again, pedagogical patterns can help guide the instructor in this.
Philosophy. Implicit in the above is a belief that students must be taught to read programs and designs before they can be expected to write them.