Robert:

Resources for Early Object Design Education

OOPSLA’97 Workshop Report

Organizers:

Robert Biddle, Victoria University, New Zealand

robert@comp.vuw.ac.nz

Rick Mercer, Penn State Berks-Lehigh Valley

Overview

Object-Oriented programming is now the basis for many introductory courses in programming. But while it seems students successfully learn program implementation in such courses, it is less clear whether they learn program design. In 1996 we organized a workshop to address how to better teach OO design in first year computer science courses in universities and colleges. In 1997 we organized a follow-up workshop on resources to assist educators in teaching OO design early.

Our workshops focus on object design, rather than implementation, and on the different issues involved in teaching and learning object design. We are striving to involve viewpoints and ideas from educators, learners, and industry in a cooperative effort. There are many issues to address, including: the nature of good design, how it can be taught, learned, and assessed -- and how tools can help. Our intention is to help educators perform their role more successfully. We explicitly avoid language wars, and specifically welcome people from both academia and industry to contribute their perspectives.

Our initial goal in 1996 was to investigate general experience and ideas related to effective early teaching and learning of object design. We hoped to determine useful guidelines for educators that better prepare students for future courses and industry. Our goal for 1997 emerged from one of the outcomes of the 1996 workshop: there was a widespread call for resources to enable teachers to emphasize object design more effectively. Therefore the 1997 workshop specifically addressed the need for a resource base for emphasising object design in the early years. Our goal was to investigate ways of identifying, classifying, cataloging, and disseminating resources for early object design education.

Beginnings: 1996 Workshop

The title for the 1996 workshop was: ``Teaching and Learning Object Design in the First Academic Year''. Our approach was broad, and we invited presentations and collaborative sessions to investigate methodologies, tools, philosophies, case studies, and assessment techniques.

The workshop consisted of four major presentations, many short presentations, a demonstration, and much discussion. The major presentations covered several significant views of the topic: the difficulty of teaching design before anything else, how to use design modification as a strategy for teaching design, use of OO patterns right at the beginning, and dealing with large scale programming before small scale programming. The demonstration involved actual students, and showed them learning design via role-playing and a responsibility driven method.

The discussion covered a wide range of topics, and 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. 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 concern design only. There was strong agreement that design should be addressed in realistic contexts. We felt that there was a need for more resources to support teaching and learning OO design early: especially more appropriate example problems.

We had set out to generally tackle the idea of explicitly teaching OO design in the first year. We did make a beginning, and decided to proceed further. The workshop reported to the Educators Symposium, and took part in the report from the symposium to the main OOPSLA conference. The full report from the workshop was published in the addenda to the Oopsla 96 Proceedings, and is also available on our web page (which is cited at the end of this report).

3. The Next Step: 1997 Workshop Plan

We organized the 1997 workshop to follow on from the 1996 one. The earlier workshop resulted in agreement that object design should be emphasized to a greater extent in the early stages of computer science education, and a number of convincing approaches were presented. However, in the 1996 workshop there was also a widespread call for resources to enable teachers to emphasize object design more effectively. This new 1997 workshop addressed the need for a resource base for emphasizing object design in the early years.

Prospective participants were invited to submit a sample resource for presentation at the morning session of the workshop. With these as a focus we would spend the afternoon in discussion. We would first discuss the resources presented in the morning, and in general address how best to evaluate and categorize these kinds of resources. Later we planned to address how to facilitate sharing resources on an ongoing basis.

Resource Submissions

The main aim of any resource and any document describing it should be to assist educators to be more effective in helping learners understand object design. However, the first step to accomplishing this is to assist educators locate the kind of resource they are seeking. To address this concern, we feel consistency of presentation be useful, and that the document should make the role of the resource clear. We strongly suggested all contributors follow the outline given below.

The outline comes from the "patterns" movement, in particular the workshops in "pedagogical" patterns, and we acknowledge our debt to those workshops. We know that many useful resources have already been written up and published in the literature, often as part of more comprehensive work in research, education, or professional practice. For various reasons these resources may not conform to our outline. For example, the resource may be a videotape, or may be a book under copyright. However, we did not wish to exclude such resources. Accordingly, we invited documents describing these resources, while not duplicating them. The outline below was to be followed, and a reference made to the primary work in the literature.

4.1 The Resource Pattern:

Title:

Give your resource a succinct descriptive name.

Author:

Give name(s), affiliation(s), and email address(es).

Motivation:

Explain the need that gives rise to this resource being useful. Remember an educator looking for a resource will be aware of the nature a problem, and may not have yet committed to any particular kind of solution.

Applicability:

State immediately any particular strengths, weaknesses, or restrictions that this resource has in assisting educators interested in addressing the problem motivated above.

Structure:

Give a structural outline as to what the resource actually is. This should not involve explaining the resource in detail, but should give the reader a good understanding of what kind of approach it involves, and the general way it works.

Consequences:

Explain the expected outcome of using this resource, making clear the advantages to be gained.

Implementation:

Explain the resource in sufficient detail that the reader will be able to understand how to use the resource, and why the consequences and applicability follow.

Related Resources:

List any related resources. As we are just starting, this could be left blank, or could refer to any well-known resources of various kinds that it might be helpful to point out connections with.

Example Instances:

Give at least on example showing how the resource provides assistance. Be specific, and choose a specific educational context and a specific application of the resource.

References:

Please cite only work that is directly relevant to your resource, and will help readers follow up related work. If this resource has been published in more detail or as part of a more comprehensive work, identify it here.

5. Agenda

We proposed to follow a similar plan to the 1996 workshop, which worked very successfully. Broadly, we would use the morning for specific presentations, and with these presentations to focus us, use the afternoon for discussion. Also as in 1996, we would split the morning presentations into major presentations, to allow enough time for critical ideas, and brief presentations, to allow everyone to outline their approach and hence facilitate later discussion.

In fact things did not turn out quite as we planned. Our workshop was scheduled for the full day, as last year. However, in 1997 there was another workshop on education and object-orientation scheduled for a half-day on the same afternoon as our workshop. Several people wanted to attend both workshops, and so our workshop was limited to the morning. We retained the longer presentations, dispensed with the shorter presentations, and tried to fit as much discussion as we could into the remainder. It was rushed, and less than ideal, but we nevertheless accomplished the main goals of the workshop.

Presentations

We asked those attending the workshop to submit sample resources, both to start our repository and to focus our discussions. A number of interesting resources were submitted, and several were presented at the workshop. Below are listed those who submitted and presented their resources, with enough detail from the resource to give the general idea. The complete resources, and others not presented, are available from our web page.

Chris Phillips:

Data Abstraction for Apprentice Software Engineers

GOAL: To provide a design notation for Programmer Defined Types (PDTs) employed in an OO-based approach to teaching programming and software engineering. (We use the term PDT to describe what in the past has been known as Abstract Data Types - ADTs.) Also, to provide a WWW-based reference for existing PDTs developed to support that course.

MOTIVATION: Even when a student knows what they want to do, the question of how to do it still remains to be solved. We attempt to address both issues by presenting a design notation, based on BS6224, for encapsulating PDT interfaces. We also present an online reference that provides details of what PDTs are available, their interfaces, and more detailed descriptions to aid the transition from program design to actual code.

Kerstin Voigt:

Wholistic Introduction to Object Design:

"Give them OO, and Give Them All of It"

GOAL: To take a decidedly less timid approach to the teaching of OO and object design in particular. To focus the teaching of OO in weeks 1-4 of a 10-week quarter on CS-I on introducing the notion of an object in a way that is informal, appealing to students' intuitions on everyday objects, and does not shy away from introducing the central OO concepts such as aggregation, and yes, inheritance and polymorphism. Brief justification up front: The underlying premise of this seemingly radical approach to OO teaching is that the notion of an "object", the fact that objects can be composites (aggregation) of other objects, that objects can be specialized cases of other objects (inheritance), and that different objects may exhibit different behaviors that are nevertheless referenced under a shared name, are not inherently difficult. On the contrary, any human who manages to sustain a successful existence in our physical world is bound to find these concepts fairly intuitive and accessible. We claim that the conceptualization of a class (description of a category of objects) is no more difficult to grasp than the notion of, say, a conditional statement (if-then-else), or repetition. We propose to teach the first 1-4 crucial weeks of OO by tapping into students experience/intuitions with and about the physical world.

Don Bagert:

Object-Oriented Design Resources for CS2

This document is intend to give the reader some idea about how the author teaches object-oriented analysis and design in a "CS2" course; that is, in a second programming course in an undergraduate computer science curriculum. At Texas Tech, this course (C S 2463, Fundamentals of Computer Science II) teaches an introduction to object-oriented programming, data structures, and software engineering.

The first class period (after discussing the course syllabus), provides an introduction to object-oriented terminology. (It is assumed that the students has had little or no exposure to the object-oriented paradigm before this course.

The next class (after a brief review of the previous lecture) then participated in a group activity in the form of a four-stage problem for which they are to perform an object-oriented analysis. This format was presented by Alistair Cockburn at the OOPSLA '96 Workshop Teaching and Learning Object Design in the First Academic Year, and demonstrated at the concurrently-running Student DesignFest. The students do the first three stages of the analysis in groups of about three, and the last stage in a group of about six. The author, in presenting this problem, has the students treat it as an object-oriented analysis of the customer's requirements for the system, rather than as a design.

The third and final class in this sequence covers object-oriented design, and links these concepts to the basic ideas behind software engineering. In particular, architectural design (in the form of CRC cards, although a CASE tool may be used in future semesters) and detailed design are both discussed.

Robert Biddle:

Audio Object Analogies

GOAL: To help explain object design principles by means of a consistent set of analogies from audio system design to object-oriented design.

MOTIVATION: Students learning programming for the first time have difficulty in learning design because they lack experience with the effects of good or bad program design. To address this lack of experience, we propose harnessing experience from another domain. The domain we suggest is audio systems, meaning CD players, tape-recorders, speakers, headphones, and so on. Most students have experience with these systems, and are able to understand the implications of various designs. We establish analogies from principles of audio system design to principles of OOD, and then recall them when discussing specific object designs.

Rick Mercer:

Scripted Scenarios

GOAL: To teach beginners an informal approach to object-oriented software development. To use the concepts of a first course within the context of an interesting case study .

MOTIVATION: Educators often cite the need to get more design into the first year of the computer science curriculum. At the same time there is a desire to de-emphasize syntax. This resource is intended to provide the context to accomplish these two desirable goals. Educators should be able to reuse this approach with one of many problem statements in the literature that lend themselves to an object-oriented solution.

This case study provides a template for analyzing, designing, and implementing software in an object-oriented fashion. It is written so novices can follow it. The template can be used for any problem statement. Lecture or lab time can be spent with one group of students role playing the objects. The educator can facilitate in the role of the "object expert", which is built into the informal the case study template. This approach encourages team projects, which can be done in lecture halls of any size. It emphasizes the importance of analysis in both understanding the problem and modeling the solution in terms of objects. Students see some of the simpler relationships in object-oriented software--uses and containment. It put syntax and implementation into an appropriate context.

As well as these prepared resources, there were also brief presentations by several other participants who outlined their approach. Mary Lynn Manns described the continuing work of the Pedagogical Patterns group, of which she is an organizer, and drew attention to their plans to publish a collection of pedagogical patterns, and their invitations for people to submit candidate patterns. Joe Bergin and Sarah Stoecklin had not prepared resources, but invited participants to explore their extensive web pages relating to their OO work in introductory computing courses (the addresses are shown at the end of this paper).

General Discussion and Conclusions

As we had decided to limit the workshop to a half-day, our time for discussion was very short. Accordingly, we concentrated mostly on practical issues necessary to continue our work. There was quick consensus that we were still on the right track, that an early emphasis on design still seemed attractive, and that sharing resources was an important step. We also agreed that a web repository was an obvious way to facilitate and coordinate sharing.

We then discussed what kinds of resources were most needed. Suggestions widely supported were:

Projects for students, classified as to difficulty and size of groups for which they would be suitable.

Design notations suitable for beginners, or guidelines suitable for beginners for standard notations.

Sample syllabuses.

Case studies.

Simple CASE tools.

Book reviews.

There was also discussion about the way a resource repository should be organized, and several people thought it important that it should be more than a passive storehouse. In particular, it was suggested that:

Facilities should be put in place so that feedback and comments could be sent to the resource providers.

Resources might also be reviewed, and the reviews posted in the repository with the resources themselves.

Provision should be made for a "Resource Wanted" list, so that people could suggest resources that they would find useful.

Access to the resources should be monitored, so that it was easy to tell which resources were being inspected and retrieved.

All participants agreed that resource sharing was helpful. However, there was also some discussion about the difficulties involved. One difficult mentioned involved legalities: there would be problems in making copyright material available in a repository. However, it seemed likely that publishers or other copyright holders might well agree to summaries being offered as resources, with references to the complete copyright material.

A more general set of difficulties simply concerned how easy it would be to create and use resources. For a resource user, it was seen as easy to retrieve a resource in the form it was created, but arduous to adapt resources for use elsewhere; if too arduous it would not be worthwhile. For a resource provider, it was seen as easy to provide a resource in the form it was created, but arduous to make it general purpose. While many people were happy to share the results of their work, they felt unable to do more work to generalize resources for other people.

We discussed whether it would be possible for a repository to be seen as a journal, where contributions were refereed and successful resources regarded in similarly to research publications. We agreed that this might be a reasonable aim, but that we should concentrate in the short term in better sharing what we already can make available.

As approved by the workshop, the repository will begin with the papers and resources from the 1996 and 1997 workshops, and will be accessible from the workshop web page (given below). The web page and repository will be developed further over the year in accordance with the ideas of the workshop. New resources are welcome: please send e-mail to the organizers!

Even though our time for discussion was short, we did venture a little outside the immediate topic. One topic raised was familiar from the 1996 workshop: how best to evaluate student design, especially given the large class sizes and tight schedules of first year courses. Like resource sharing, this topic was identified in 1996 as a key area in which progress needed to be made. With resource sharing addressed now in 1997, design evaluation now seems like an excellent next candidate for our attention!

Internet Addresses: