Teaching and Learning Object Design in the First Academic Year
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.
2. Workshop Presentations
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: Object Design in the First Year: An Oxymoron
Abstract: What is meant by "Object Design"? Certainly we should analyze the problem before discussing viewpoints and solutions. In this paper I'll first discuss different views of design (as opposed to, e.g., programming). Next I'll discuss how we as educators can build a framework in the first year on which to build design skills, but that concentration on design per se can only come if we either accept a weakened definition of design or measure our success with metrics that measure anything successfully. Finally, I will discuss how we have adopted object-oriented techniques in our first two years (and, to a degree, in later courses) by building a framework on which real design skills can be taught.
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.
M. D. Evans: CS1 As An Architectural Design Course
Abstract: Current CS1 courses purport to teach an introduction to design, often providing an early introduction to the software engineering life-cycle and to objects. This paper claims that such courses at best teach only micro-design - the self-contained design of small isolated data components and algorithms. Conversely, in real-world design, issues of a macro-perspective which emphasize the architectural organization and structural connections between and among identified components are of significantly more importance than those of the micro-design perspective. This paper proposes, for a CS1 course, a case-study-driven approach to teaching object-oriented design from the macro-design perspective. The design and implementation hierarchy employed also teaches micro-design and its C++ implementation. Some observations of the author's experience of teaching such a course are provided.
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.
Stephen R. Schach: The Importance Of Object Design Modification
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.
Eugene Wallingford: Teaching Object Patterns in the First Course
Abstract: This paper advocates an approach to teaching introductory computer science courses based on the idea of object patterns. Such patterns give students an adequate vocabulary for analyzing problems, designing solutions, and implementing programs that is both abstract enough to make learning design possible and concrete enough to enable generation of effective, readable code.
Eugene Wallingford also discussed teaching strategy for introducing design, but his focus was on the use of OO design patterns. Like Astrachan, he started by reminding us how much needs to be learned in a first course, and suggested it was important to discuss computing basics in the early weeks. However, he has taken the idea of design patterns from research and used simple patterns to teach design concepts at an early stage in student programming. The students learn to identify the patterns, practice applying them, and develop a growing catalog of patterns as they learn. He points out that patterns facilitate discussion, make it easier to address example situations, and help provide guidance for implementation. Wallingford sees patterns as providing scaffolding, and says the advantage applies from analysis through design to implementation. He is developing a set of patterns appropriate for a first year course, starting with simple state objects, and extending to collections and iterators.
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..
3. Student Design Experiment
The presentations above occupied the morning of the workshop, but another event was happening at the same time. Alistair Cockburn had written a position paper (Teaching OO Design is Teaching How to Assess the Design’s Future) which is available from the web page. But instead of presenting his paper, he offered a demonstration of some of the key ideas. Alistair Cockburn:
"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.
4. General Discussion and Conclusions
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:
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 (email@example.com). We hope to coordinate a continuing effort to change the face of teaching and learning object design in the first academic year.
6. Workshop Attendees
Erzsébet Angster, Dennis Gábor College, Hungary
Owen Astrachan, Duke University
Don Bagert, Texas Tech University
Martin Barrett, East Tennessee State University
Robert Biddle, Victoria University, New Zealand
Mike Clancy, University of California Berkeley
Alistair Cockburn, Humans and Technology
Michael Creek, Swinburne Institute of Tech., Australia
Robert Duvall, Brown University
Mike Evans, Simon Fraser University, Canada
A. Fernandez, LIFIA, Argentina
Amy S. Gause, Knowledge Systems Corporation
Urs Hoelzle, University of California Santa Barbara
F. A. Hosch, University of New Orleans
Eric Herness, IBM and Winona State University
Ramiro Maciel, LIFIA, Argentina
Rick Mercer, Penn State Berks
Jaime Niqo, University of New Orleans
Judit Nyékyné-Gaizler, Eötvös Loránd Univ., Hungary
Stephen Schach, Vanderbilt University
Kerstin Voigt, California State Univ., San Bernadino
Gene Wallingford, University of Nothern Iowa
Michael Whitelaw, Charles Sturt University, Australia
Robert Zimmer, Brunel University, UK
Jennifer Brown, Sami Rollins
Rishi Batra, Aaron Leung,
Tina Smilkstein, Mary Wholey
The workshop organizers are grateful to the student volunteers, and to Mike Clancy for organizing their participation.