Department of Computer Science
University of Northern Iowa
Appears in OOPSLA'98 Educators Symposium Notes
Helping novice students learn how to write programs well is a difficult task. Students must learn, among other things, how to use a programming language; how to create readable, modifiable code; how to evaluate the quality of programs; and how to modify existing code. One way for us to help them is to have them study and use the patterns of good programs, just as experts do. Six educators interested in the use of patterns in the undergraduate computer science curriculum gathered for an intensive three-day workshop at ChiliPLoP'98 to consider this possibility. This report describes the origin of the Elementary Patterns workshop, the work done at the workshop, and some of the lessons that we learned. I also outline some of the post-workshop activities intended to help develop further the idea of elementary patterns in computer science education.
Computer science education, patterns, pattern languages, CS1, CS2.
The goal of the software patterns community is to build a body of literature to support the design and development of good software. Patterns have been used to document not only software solutions but also software development organization and process. Others have written patterns of good exposition and effective pedagogical practices.
The patterns community runs a series of annual conferences called Pattern Languages of Programming (PLoP), at which pattern authors share and improve their work through writers workshops. The environment at PLoP is supportive and relaxed--but the conference focuses on improving the presentation of documented patterns. It provides only informal support for groups of practitioners interested in working together to explore the patterns of a specific domain.
The organizers of ChiliPLoP'98 sought to provide an environment for such collaborative exploration. Billed as a "different kind of PLoP", ChiliPLoP offered two tracks. In the newcomer track, self-professed patterns novices worked with expert patterns trainers to learn how to find and write patterns. In "hot topic" track, small groups of domain experts worked on the discovery, use, and application of patterns in their domains. Groups worked in the areas of telecommunications, software organizations, software configuration management, and patterns of time in information.
A fifth hot topic workshop was titled "Elementary Patterns and their Role in Instruction". This workshop explored the teaching side of patterns, especially patterns appropriate for novices first learning to design and write programs. We call such patterns elementary patterns.
Most patterns in the published literature document rather advanced techniques in software architecture, design, and implementation. They provide a powerful design vocabulary and facilitate the development of good software in the face of complexity. But they also presume a high level of software development maturity and experience. What about designers and programmers who lack the background and experience to understand such patterns? How can we help such folks reach a level of competency at which the advanced patterns are useful to them?
Computer science (CS) educators face an extreme form of this problem. Their students begin with little or no experience and hope to learn the art of computer programming. How can CS faculty help them to learn to use a programming language, create readable, modifiable code, evaluate the quality of programs, and modify existing code? Patterns may help to provide a culture for novices learning how to program. Ultimately, the software patterns movement is about communication: experienced developers documenting for their benefit and for the benefit of others the art of building software systems. As CS educators, we hope to communicate the knowledge, methodology, and culture of computer science. Perhaps patterns can help teachers communicate the art of building software systems to undergraduate students. Out of this idea grew the motivation for the Elementary Patterns workshop at ChiliPLoP.
Over the last few years, activity in both the patterns community and the CS education community have demonstrated that many practitioners and academics were interested in the idea of elementary patterns. In the patterns community, patterns at a level appropriate for relative novices have become more common. For example, many of Kent Beck's Smalltalk Best Practice Patterns  document ideas and techniques that we teach in object-oriented (OO) programming courses. Ken Auer's self-encapsulation patterns  walk a class designer through the process of creating robust, reusable classes. At the PLoP'97 conference, James Noble presented patterns of relationships among objects  and patterns of method signatures .
At the same time, CS academics themselves were beginning to explore the use of patterns in their courses. This exploration was a natural outgrowth of earlier work, in the same spirit as patterns, by people such as Soloway  and Linn and Clancey . An example of academic patterns work is Roundabout, my recursive programming pattern language reviewed at PLoP'97 . I use Roundabout to teach students how to write recursive programs in a functional programming language and to teach the basics of recursion in my data structures course. The 1998 SIGCSE Technical Symposium featured a number of papers on patterns and their uses in early CS courses. Astrachan described One Loop for Linear Structures , a pattern of loops that operate on linear data structures. Nguyen  and Goodrich et al.  reported the use of several patterns from Design Patterns  to teach data structures. On a slightly different note, Reed  described the use of a binary reduction pattern as an organizing theme for his CS1 course.
These patterns and uses of patterns indicated that elementary patterns were indeed a hot topic among practitioners and CS academics. ChiliPLoP'98 offered a convenient setting for a group of people to explore the domain more deeply.
Among the goals of the hot topic were to develop methods of using patterns and pattern languages to energize the early computer science curriculum and to prepare students to find and use patterns in their work. One of my personal goals as hot topic organizer was to begin to map out a pattern language that my first-year students could use to design, write, and modify programs.
The workshop's call for participation asked prospective participants to submit (1) a description of a course they teach using patterns, either in academia or industry, (2) a proposed elementary pattern language or catalog for teaching some topic to novices, or (3) a draft outline of an elementary textbook organized around patterns. We had hoped to receive requests to participate from practitioners and industry trainers as well as CS academics, but all applicants were full-time faculty members. On the basis of the submissions received, we selected six people were to participated in the three-day Elementary Patterns workshop:
Not only were all six participants computer science educators, but they were also all experienced in and deeply interested in the first-year courses typically taught to undergraduate CS students. This common interest provided a natural focus for the workshop.
Prior to meeting at ChiliPLoP, we read each others' submissions and previous patterns papers. We also began to formulate a list of open questions relevant to the workshop. Among these questions were:
Another, somewhat more sociological question also arose: How can our efforts working on and with elementary patterns help educators unfamiliar with patterns see past the hype to the value that patterns bring to software development and understanding? This remains an important concern as people begin to explore elementary patterns more deeply.
We began the workshop by discussing general principles of patterns and pattern languages and how they might be used in our first year courses. Fairly soon we decided that the best way to start is by considering the kinds of problems that first-year students have when writing programs. These problems are likely to highlight patterns of good programs that the students do not yet know or understand. Without such focus, trying to mine patterns in such simple programs is more likely to lead to platitudes that do not help students understand.
We then split into two groups for focused pattern mining and writing. One group (Astrachan, Mercer, and me) began to develop of a set of patterns for writing loops. Another group (Bergin, Duvall, and Epp) explored issues in object-oriented design.
This group began with a simple understanding: novice programmers often have trouble writing loops. Our discussion quickly turned toward war stories of specific loops that we had asked students to write, which caused them difficulties. In one assignment, students were to write code to compute the date on which Thanksgiving, the fourth Thursday in November, occurs. In another, students were to write code to identify the extreme values in a stream. Both of these tasks pose subtle problems for the initialization of variables. Over the course of the next two days, we tried to capture the patterns of good solutions to these tasks. The result was two patterns that we called Loop Invariant and Extreme Values. At the same time, we tried to identify other patterns that students might use in conjunction with these. Our goal was to mine a small pattern language for writing loops from our experience as loop writers and as teachers of beginning loop writers.
This group worked through a number of modeling problems as a way to identify patterns of OO design appropriate for first-year students. We began with an analysis of the game Mancala. In this exercise, we were attempting to extract the essentials of responsibility-driven design in terms of a set of patterns. From there, we went on to look at the elements of information hiding and how its essential features might be distilled into a set of patterns. We then spent some time examining a robots-and-rockets simulation problem, designed by Epp to help teach multithreading in the first year. This analysis led to a set of competing patterns for event-driven processing, which we applied to the design of a simple calculator program. The task faced by the object design group was more difficult than that facing the loops group in at least one way: we have much more experience teaching loops to first-year students than we do teaching OO design. Casting patterns at the right level becomes correspondingly harder.
We wrapped up the workshop with a discussion of what we had learned, what we would like to do next, and what some of the key issues in using patterns to teach CS are. From this discussion, we identified a few modest goals and recommendations for anyone interested in working on elementary patterns for use in the classroom.
Ultimately, the goal of work on elementary patterns is to transform courses from "learning C++" or "learning Java" to learning how to program. By this we mean to integrate a higher-level of thinking about programs into the first-year courses. Bergin sometimes refers to this as system-level thinking.
Ultimately, students will be the users of the patterns and pattern languages that we document. At least initially, though, CS faculty members comprise an important audience, too. To the extent that the use of patterns opens new avenues for programming instruction, the roles and methods of the instructors must change. Questions of pedagogy will likely remain critical even after we are able to demonstrate an effective pattern language of programming to our students.
As we begin to write elementary patterns, we must resist the temptation to "create" patterns, to write new solutions with which we have no experience. Certainly, there is a place for innovation, but that is not the role of patterns. Instead, we want to identify patterns of good programs that our students write and identify how they fit together to form a program. One way to resist the temptation to innovate is to begin with a focus on problems that our students encounter. Focus on concrete problems that students face--start with a specific programming assignment and specific code, both good and bad solutions. At the same time, resist the urge to "go meta-" too early. Over-abstraction can dull a student's attention to the subtleties of a problem and interfere with understanding the pattern.
Finally, we must consider to what extent, if at all, we need to change the form of our patterns and pattern languages in order to incorporate additional pedagogical material, such as exercises or extra discussion of the forces and consequences of the pattern.
One of the primary goals of the hot topic tracks at ChiliPLoP'98 was to foster the development of communities centered on important issues involving patterns. As such, the Elementary Patterns workshop should be judged more by what happens after our three days in Wickenburg than by what happened there.
The members of the workshop intends to carry on the work begun at ChiliPLoP in a variety of ways. Here is a brief list to start:
Joe also hosts a patterns page with pointers to relevant documents.
We sincerely hope that others in the patterns community, the academic CS community, and the OO practitioner community will join is in the effort to improve undergraduate computer science education. Some believe that the use of patterns and pattern languages could lead to a radically different way of teaching computer science. If you are interested in any way, please visit the Elementary Patterns home page, subscribe to the discussion list, and join us!
I thank the participants of the Elementary Patterns workshop for their help with this report, especially Joe Bergin, who wrote an early workshop report draft from which I borrowed liberally. We all thank Linda Rising and the folks behind ChiliPLoP'98--a first-rate event in a first-rate location.