Teaching and Learning Object Design in the First Academic Year

Organizers:

Rick Mercer, Penn State Berks

Robert Biddle, Victoria University, New ZealandZ

Mike Clancy, University of California, Berkeley

Robert Duvall, Brown University

Alistair Cockburn, Humans and Technology

Object-Oriented programming is now the basis for many introductory courses in programming. While it seems students successfully learn program implementation in such courses, it is less clear whether they learn program design. This workshop involved presentations and collaborative sessions to investigate methodologies, tools, philosophies, case studies, and assessment techniques that effectively support teaching and learning object design in the first academic year.

We hope to determine useful guidelines for educators that better prepare students for future courses and industry. The workshop focused on object design, rather than implementation, and on the different issues involved in teaching and learning object design. We had viewpoints and ideas from educators, learners, and industry in a cooperative effort. There were many issues to address, including: the nature of good design, how it can be taught, learned, and assessed—and what tools can help.

The organizers selected position papers for short presentations, and some papers wereill be chosen as the basis for more intensive examination and discussion. There were 29 participants from industry and academia, including many respected educators and noted textbook authors. Six students participated in an experiment on teaching design.

For the workshop all participants had submitted position papers outlining their particular point of view and contribution to the workshop. The organizers selected five papers concerning issues central to the workshop for full presentation. The abstracts for these papers are listed below, together with some notes from each of the presentations. All position papers for this workshop are available at: http://www.bk.psu.edu/faculty/mercer/odesign.htm

Owen Astrachan addressed the question of design in the first year directly, and the viewpoint of existing curricular practice. He reminded us that students in the first year need to learn many things, and discusses ways of introducing a stronger emphasis on design while retaining strengths of current best practice. For example, he suggested making students more aware of different design possibilities, and avoiding describing programs in terms of their low-level structure, e.g. how many functions they have. However, he suggested we can talk about low-level design as well as high-level design. As strategies for teaching about design, Astrachan favors an apprenticeship model, and mentions such techniques as use-case studies and modification exercises. At a more tactical level, he mentioned students need for explicit assessment criteria, and suggests face-to-face grading. Finally, Astrachan advises caution in attempting to introduce design too quickly, and advises spreading the introduction over two or even three semesters.

Michael Evans proposed an alternative structure for a first year course, and reported on his experience in trying the new approach. Evans discussed the implications of the differences between "programming in the small", which first courses typically focus on, with "programming in the large", which is where important design issues arise. The alternative approach involves starting with "programming in the large", and delays introduction of low-level details in favor of greater emphasis on large-scale design. This did result in some initial confusion for the students, but Evans found that the confusion abated, and that the students carried the concern with design into later work. There are important tactical considerations, and Evans explained how he uses easily understood objects and components so that the students can make a beginning, and then address implementation details afterward. This strongly supports a paradigm for design that begins with a focus on abstraction, and only later on implementation. Evans also pointed out that advantage of the approach is that students like the challenge of thinking big, and are strongly motivated by the larger scale examples used in the new approach.

Abstract: Many instructors believe that only after students have acquired experience in modifying existing designs should they then progress to creating new designs from scratch. In this position paper, four advantages of modifying existing object designs are put forward. First, it would encourage those instructors who believe in teaching design via modification of existing designs to introduce object design into the first year curriculum. Second, object design modification can be used to teach abstract concepts like cohesion and coupling to first year students. Third, object design modification can assist in clarifying the issue of design versus implementation. Fourth, students can be exposed to a greater variety of different good designs in a course that is based on design modification.

Stephen Schach focused on the issue of how to teach design, and advocated beginning by focusing on modifying existing designs. Like Evans, Schach suggested many aspects of design can not be easily discussed with small-scale examples. He also suggests that modification allows early introduction of more abstract concepts for discussing design. Further, Schach suggests that a key distinction is difficult for students to make when they study design starting from scratch. We typically base a lot on the difference between abstract interface and concrete implementation, yet Schach points out that beginners can have great difficulty seeing this boundary when looking at toy examples. Finally, he makes a very practical point about starting with modification: it makes available a great range of examples and different designs that would be impossible to equal when starting design from scratch.

The papers above addressed some central concerns of the workshop, and combined together well as a basis for discussion. However, there were many other very worthwhile position papers, and the authors were invited to make short presentations. Though severely restricted for time, these presentations were of excellent quality, and facilitated later discussion by allowing all workshop participants to outline their particular point of view. The topics discussed covered a wide range, including use of formal methods, new tools and tool-kits, and teaching strategies. These papers are also available in full on the web page given above..

• Erzsébet Angster: A Simple OO System Pattern to Introduce OOP with Design.
• Donald J. Bagert: In Teaching the Object-Oriented Paradigm, Providing a Complete Picture is Essential.
• Martin L. Barrett: A Sequence of Class Relationships.
• Robert Biddle and Ewan Tempero: Teaching Design by Teaching Reusability.
• Mike Clancy: Case Studies.
• Amy S. Gause: The Classroom Object: As an object models the real world, so should the classroom experience.
• Eric Herness: Don’t Start with Code.
• Urs Hvlze: Teaching Design During the First Year: Just Say No.
• R. González Maciel, A. Fernández, and A. Garrido: A design toolbox for first year students.
• Jaime Niqo: Framing the Software Development Process: Three Views in the Nature of Software Solutions.
• Judit Nyékyné: Teaching Object Design through a Relational Model of Programming.
• Jaime Niqo and F.A. Hosch: Object Design vs. Algorithm Design: An introduction to problem modeling using objects.
• Michael Whitelaw: Developing Design Concepts Using Constructivist Workshops on the Internet.
• Kerstin Voigt: Ooh, it’s easy!
• Robert Zimmer and Chris Reade: Moving from a Functional to an Object Oriented Perspective as a First Programming Paradigm.

"In industry, after I teach new people how to talk about designs, I can give them real work to do and help them improve it. Until they learn design, I can't give them anything. Teaching design is easier and more important to teach early than programming. The vocabulary is simpler, the process is more natural. Once you teach the students how to talk about quality of design, they can spend the rest of their academic years learning to improve their designs and programs. They have a vocabulary for talking amongst themselves about what they have learned. They have a framework for learning how to program. As an experiment in these assertions, I am coaching six students in CRC-based design this morning in the workshop. They will present their design in the afternoon."

The students were first year computer science students from the Bay area, who had volunteered for the experiment. In two hours, they learned responsibility-based design with role playing, took on a design problem, and produced four designs to an evolving problem. They showed their designs to the workshop in the afternoon, role-playing through two of the designs, explaining why each design was better than the previous. Cockburn had acted as teacher/mentor, and said that they had arrived at the best design he had yet seen, one that none of his industry groups had managed to reach.

The students were split into two teams of three, and given 20 minutes of basic responsibility-based design, CRC cards, and role playing, starting at about 9:00. The initial design problem was: Design a coffee vending machine that offers only black coffee or coffee with whitener for $.35.

Cockburn visited the groups twice in the next hour, checking their design process. He coached them how to respond to each other and how to look for improvements in their design. At the end of the first visit, he added to the problem: Add bouillon to the machine, at $.25. At 10:20, he asked them to describe how they would change their design to incorporate use of a charge card instead of money. At about 10:30, the students joined the rest of the workshop to listen to the rest of the presentations.

At 12:15, the students were combined into a single team of six and given the fourth stage of the problem: The owner wants to include various unspecified specialty drinks made from water, hot milk and powders, at least including cappucino, mocha, and espresso, and plans to change the drinks in the machine frequently to respond to market trends. The prices will change accordingly. At 13:00 they were asked to present their four designs to the workshop.

Cockburn said that he had to stop coaching them during this last part of the design, because they had gone farther than any other novice group he had taught, and he wanted to see where they would go on their own (the students said they were frustrated, because he stopped giving them hints). As anticipated, they had initial difficulty understanding the notion of a design made of communicating components, and articulating each component's responsibility. He was surprised when they got the idea of drink knowing its own price, as that required a major shift in thinking. From there, they role-played the designs, and found the weaknesses in the communication patterns. They were able to spot them intuitively, if not obviously.

The students showed their initial paper design to the workshop group, then walked through the bouillon design, role-playing the components. They described what had to be modified to permit credit card usage. Finally, they described the major change they had made to their design for the fourth stage, and why they felt it was a sounder design then their previous ones. They walked through buying a drink, and changing the drinks in the machine. The room was hushed as the students finished their description.

After the presentation, workshop participants asked the students for comments on various aspects of their experience in doing the project. To start with, they commented on what they found helped them most, and all agreed that both the role-playing and the group work were vital. When asked what they found most difficult about the project, they mentioned problems of partitioning the coffee machine into parts, keeping track of responsibilities, and understanding what an object should know about itself and other objects. The students reported finding the experience quite different from what they were used to, and found what they knew about programming to be a hindrance! (For example, one mentioned being distracted by thinking about parameter passing.)

There were at least two instances that indicated the usefulness of placing object design issues into the context of a design problem. The terms "high cohesion" and "low coupling" came up as design heuristics. Mike Clancy objected that students would not know what these terms meant. Every one of the students confirmed they did not. After Astrachan and Cockburn spent about one minute explaining what these terms meant in terms of the design problem, the students indicated they now understood. In another case, one of the students complained that she felt uncomfortable trying to make design decisions. This question was then posed: "Do you think it is better to make these decisions now rather than after 30,000 coffee machines were distributed around the country?" The students nodded yes. It seemed clear they saw the big picture and the purpose of design because the question was posed in the context of a design problem.

The previous two sections have outlined the morning of the workshop: the presentations of particular points of view on our topic, and the student design project. The main focus of the afternoon of the workshop was collaborative discussion aimed at articulating our combined understanding and objectives for making further progress. The plan was to break out into small groups for discussions based on the main presentations of the morning, and then to join those discussions together.

The first item of the afternoon was the report about the student design project organized by Alistair Cockburn, as related in the previous section. After this report there was discussion about the students experience, and with this to focus our thoughts we moved rapidly and constructively toward more general concerns. Although the group was large, the discussion seemed sufficiently well-organized and compelling that we dispensed with breaking out into smaller groups.

The discussion covered a wide range of topics, considering the perspective of the learner as well as the teacher, and constantly relating new ideas to existing pressures of curricula and time constraints. It soon became fairly clear that most people saw the general approach as very attractive. Many people discussed how the typical current concentration on implementation overemphasizes details at the expense of principles of software structure at the abstract level. This both obscures how the details are derived from the principles, and avoids the important issue of applying the abstract principles to software development.

While there was broad agreement about the importance of introducing design earlier, there were more diverse comments about practicalities and implications involved in addressing the matter. To summarize, we agreed that there were three main threads to the discussion:

1. What is the nature of good design??

• * Ultimately, good design is that which supports: *communication, implementation, maintenance, modification, reuse, …

1. How can we easily determine good design?

• Empirical measures (coupling, cohesion)
• Subjective measures (naming, heuristics)

1. What strategies aid teaching good design?

• Modification, Apprenticeship, Patterns, Case Studies, Role Playing, …
• Easy Analysis via Familiar Domains

Looking at this framework, it seems the first issue is of ultimate importance to us (and our students) as software engineers, but that as educators we may properly concentrate on the third issue (as indeed we did). However, for many of the teaching strategies, a better understanding of the second issue would be beneficial.

To conclude our day, we returned to a number of specific items to review where we had consensus, and where we still had disagreements. It turned out we still had disagreements about whether or not it was possible to teach design before students had learned about implementation at all. Moreover, there was also disagreement about whether to address design first by modifying existing designs, or whether to start with new design. More generally, some people felt that the existing infrastructure would support addressing OO design, while others felt it was inadequate.

We had a consensus that explicitly addressing design at first year was both possible and beneficial. However, we also all agreed that students would not be great designers after first year, and that the first year program should not only concern design. There was strong agreement that design should be addressed in realistic contexts. We felt that there was a need for more appropriate example problems, and acknowledged no current first year texts truly support teaching and learning of OO design. Several people remarked how they had found work such as Gamma et al. (1994) useful and inspirational, but very demanding reading; they felt more work was necessary to bring this research to introductory level.

There was also agreement about the need to better investigate various practical aspects of strategy that might be especially difficult in first teaching, such as easier determination of good design, and small group management. Several people suggested Riel (1996) as a place to start in considering how heuristics might be used to more easily determine and assess good design.

We set out to generally tackle the idea of explicitly teaching OO design in the first year. We have made a beginning, and decided to proceed further. Through the presentations in the morning, we examined a variety of current approaches relevant to the idea. Thanks to the student design project, we saw a vivid experience of one approach first hand. In our subsequent discussion, we clarified our agreement on the principles involved, noted some differences, and agreed on some areas for early investigation and development.

The workshop reported to the Educators Symposium, and took part in the report from the symposium to the main OOPSLA conference. We are currently continuing discussion via a mailing list and we invite those interested to join us (odesign@psuvm.psu.edu). We hope to coordinate a continuing effort to change the face of teaching and learning object design in the first academic year.

Erzsébet Angster, Dennis Gábor College, Hungary

<angster@kanga.gd-szamalk.hu>

Owen Astrachan, Duke University

<ola@cs.duke.edu>

Don Bagert, Texas Tech University

<bagert@cs.coe.ttu.edu>

Martin Barrett, East Tennessee State University

<barrettm@etsu.etsu-tn.edu>

Robert Biddle, Victoria University, New Zealand

<robert@comp.vuw.ac.nz>

Mike Clancy, University of California Berkeley

<clancy@eecs.berkeley.edu>

Alistair Cockburn, Humans and Technology

<acockburn@aol.com>

Michael Creek, Swinburne Institute of Tech., Australia

<mjc@saturn.csse.swin.edu.au>

Robert Duvall, Brown University

<rcd@cs.brown.edu>

Mike Evans, Simon Fraser University, Canada

<evans@cs.sfu.ca>

A. Fernandez, LIFIA, Argentina

<casco@sol.info.unlp.edu.ar>

Amy S. Gause, Knowledge Systems Corporation

<agause@ksccary.com>

Urs Hoelzle, University of California Santa Barbara

<urs@cs.ucsb.edu>

F. A. Hosch, University of New Orleans

<fred@cs.uno.edu>

Eric Herness, IBM and Winona State University

<herness@vnet.ibm.com>

Ramiro Maciel, LIFIA, Argentina

<ramiro@sol.info.unlp.edu.ar>

Rick Mercer, Penn State Berks

<rhm1@psuvm.psu.edu>

Jaime Niqo, University of New Orleans

<jaime@cs.uno.edu>

Judit Nyékyné-Gaizler, Eötvös Loránd Univ., Hungary

<nyeky@lngsc3.elte.hu>

Stephen Schach, Vanderbilt University

<srs@vuse.vanderbilt.edu>

Kerstin Voigt, California State Univ., San Bernadino

<voigt@csci.csusb.edu>

Gene Wallingford, University of Nothern Iowa

<wallingf@cs.uni.edu>

Michael Whitelaw, Charles Sturt University, Australia

<mwhitelaw@csu.edu.au>

Robert Zimmer, Brunel University, UK

<robert.zimmer@brunel.ac.uk>

Students:

• Mills College:

Jennifer Brown, Sami Rollins

• University of California, Berkeley: