To mail to the entire group click HERE.
This is the home page of a working group for ITiCSE 2000 held in July 2000 in Helsinki, Finland.
The focus is on non-programming resources for educators teaching the first computer science courses. The resources do not involve programming, but are generally directed at those wishing to motivate object-oriented concepts and eventually object-oriented programming.
The report that was prepared during the conference.
Other educators are invited to submit resources for this page.
ITiCSE 2000 call for participation for this working group
A design exercise that is commonly used in class in a team environment is to design a Coffee Machine [1]. This exercise follows a discussion of a day or so on objects, CRC cards, and UML style class diagrams. The format of the exercise follows the pedagogical pattern Student Design Sprint [2], in which the design exercises goes through several phases with changing requirements in each phase and a merging of small teams into increasingly larger teams in each phase. The initial statement of the problem is as follows:
Design a controller for a simple coffee machine. The front of the machine has four buttons, a coin slot, a coin return lever, and a dispensing window. The four buttons dispense the four products: black coffee, coffee with cream, coffee with sugar, coffee with cream and sugar. Coffee costs $.35 US. These requirements may change.
Teams are initially two students. After about 30 minutes of effort, CRC cards and a class diagram are required. At this time pairs of teams are merged to give teams of four and and an additional requirement is added. This can continue for as long as necessary with merging of teams and changing of requirements. The CRC cards of one or more of the iterations may be used for walk-throughs of use cases to determine if requirements are met and if communication paths are clean and clear. The class diagrams may be used by the instructor to comment on the designs. One feature of this exercise is that the students see several designs and are required to merge their own ideas with those of classmates. Good designs require five or six classes and may involve specialization (inheritance) or not.
[1] Coffee Machine, Alistair Cockburn, http://www.drdobbs.com/object-oriented-analysis-and-design-part/184403506
[2] Student Design Sprint, Joseph Bergin, http://csis.pace.edu/~bergin/fivepedpat.html
Sometimes toys can be used to give the students the right mind set. Here is one for recursion. The "base case" is exceptional. Russian nesting dolls are called matryoshka, by the way.
Question: How do you paint a Russian Doll?
Answer: If the doll cannot be divided then apply paint to it. Otherwise (using exactly this process) paint the inner doll and then apply paint to both halves of this doll.
Question: How do you count the number of levels of a Russian Doll?
Answer: Left as an exercise.
Mike Clancy (UC Berkeley) used Frisbees for years to talk about parameter passing and the difference between pass by value and pass by reference. You can find an outline of the techinque here.
Owen Astrachan (Duke) uses a toy named Icky Poo to show how the heap (free store) operates. See reference [2] above for more.
Here is another toy to introduce linked lists. Notice "null" or the "null object" at the right. (For a rock climber, really bad things happen without this termination.) We have called "new" to create the new node, but not yet linked it into the list. No data is shown here, but that is a simple extension. Just tape some slips of paper to the "biners." Disclaimer: Rock climbers really don't use the equipment in this configuration.
The kinds of problems that motivate procedural programming are not necessarily good for motivating object-oriented programming. For example, temperature converters don't make good objects, though they make good functions. In order to motivate OO, you want a problem with lots of parts (objects). Games can be good for this since games have parts. The parts need to have behavior, however, to give the right flavor. A simple example is Scrabble (http://www.scrabble.com). The board, the tiles, and the player tile racks can all be objects. However, it is hard to conceive of much behavior for any of these--especially the tiles. They can give you information when queried, but not much else, unless you want to give them interactions with the board. Monopoly (http://www.monopoly.com) on the other hand is much richer. Each square can be an object. Each group of squares, each piece, the chance cards,... can all be objects. You can discuss these things with students as a design exercise (find the objects) before you begin programming. The idea is to find the objects and their responsibilities, not to write any program that implements the game. Have the students make up CRC cards to document their ideas about object responsibilities. Have them determine how many objects there are of each class. One interesting possible object is a Move object that is created for each move by each player. If you are not familiar with CRC cards, see http://c2.com/cgi/wiki?CrcCards. Be sure to follow the link to Beck and Cunningham's paper.
One advantage of this technique is that the students often know about these games and their rules. If they don't know these two, pick one that they are familiar with.
Other things that are made up of parts and with which the students have familiarity are also useful to motivate objects. Robert Biddle (Victoria University, Wellington, NZ) motivates with Stereo equipment of various kinds. Rick Mercer (University of Arizona) uses a media Jukebox. The key is that you need lots of parts, the parts need to interact, and at least one kind of thing needs to be replicated. Students will get the wrong idea if every class represents a singleton.
Prior to programming it is a good idea to give students some ideas about objects. One way to do this is to walk through some systems, picking out objects and their responsibilities. To do this well requires that the system studied have certain characteristics. One of them is that there should be various kinds of objects and their responsibilities should be intuitively clear to the students. Another is that at least one of your object types be instantiated several times in the system so that students don't get the idea initially that there is a one to one correspondence between classes and objects. It is especially helpful if the objects in the system can be framed as providing services for other objects so that the system as a whole can be characterized as a set of client-server relationships.
One exercise with the above characteristics is the coffee machine discussed earlier on this page. Another is the Interactive Intelligent Kitchen Helper example in Section 3.4 of Tim Budd's Object-Oriented Programming with Java (Addison-Wesley, 1998).
Following up on the simple Design Exercise above, there is a game you can play with your students that gives them a good mental model of objects interacting. It can be used in a variety of ways, not necessarily connected to the coffee machine and even possibly serving as the first introduction to objects. It is described at http://csis.pace.edu/~bergin/patterns/objectgame.html
Constructivist Learning Theories say that knowledge is not transmitted from the teacher to the student, but constructed by the student him or herself to make sense of the world and to integrate new information. According to this theory, the instructor has a radically different role than in (so called) Objectivist Theories. A good introduction can be found at Elizabeth Murphy's site at Université Laval, Québec City, Québec: http://www.stemnet.nf.ca/~elmurphy/emurphy/cle.html and especially on the Characteristics page: http://www.stemnet.nf.ca/~elmurphy/emurphy/cle3.html
Last Updated: July 25, 2000