Introduction

What is a Case Study?
A cast study describes a programming problem, the process used by an expert to solve the problem, and one or more solutions to the problem. Case studies emphasize the decisions encountered by the programmer and the criteria used to choose among alternatives.

Learners are engaged in the case study through questions that are interspersed in the presentation. Students can "think along" with the experts by making predictions, helping with parts of the solution, or analyzing alternatives. More comprehensive questions ask students to modify the solution, apply the ideas to new problems, detect bugs in related problems, and reflect on their own methods for solving problems.

A sample case study is outlined in Appendix A. It deals with the problem of completing a program to print a calendar for a given year. The problem specifies that two subprograms are to be supplied: a function NumberOfDaysIn, which returns the number of days in a given month in a given year, and a procedure PrintMonth, which prints the calendar "page" for a given month. (The solution to this problem is treated in more detail in Clancy and Linn [4].)

Many CS 1 and CS 2 courses are packed with details, and instructors may believe they have no room to include case studies. In such courses, however, it is easy for students to lose sight of the big picture, gain only superficial understanding of program design, and fail to appreciate the problem-solving power of a programming language.

Perhaps another reason that case studies aren't used is an impression by instructors that novice programmers are not ready, or inclined, to appreciate the issues discussed in a case study. Personal experience and informal surveys indicate, however, that students learn from case studies both in college introductory courses and in precollege programming classes.

Lastly, instructors may not be aware of the variety of ways to incorporate case studies into their classes? hence this paper. We describe how case studies can enhance laboratory and homework exercises, small group work, examinations, and lectures. We or all colleagues at Berkeley and elsewhere have tested, in introductory and intermediate programming courses, all the techniques we describe. These techniques are useful in more advanced settings as well.

One set of exercises requires students to use a compiled executable version of the code. A version with the sizes of the data structures reduced for experiments is provided. With executable code? a source listing need not be provided? Students can still accumulate a substantial amount of information about a program, by predicting its behavior given sample input, providing input that produces a given bahavior, distinguishing legal from illegal input, and devising good examples to teach new users about the program. They can also probe the limits of the program: How much input can it handle? What are constraints on the input format? How are out-of-bounds or overflow cases handled? Finally, students can evaluate the user interface, and compare it and the program's capabilities to other similar programs they have used.

With online source code, students working together can play "debugging games". One partner (or staff member if students are to work individually) inserts a bug into the program; the other attempts to find it. This requires that students have read the program but do not have the code listing nearby. It encourages students to invent thorough sets of test data, and to think about what aspects of a program's style and organization facilitate testing and debugging.

Typical laboratory or homework assignments using online code include modifying a program to change its user interface, replacing its data structures, and adding or extending features. Such activities can be profitably done in teams as well as individually. They illustrate the importance of code readability, planning, and incremental development, and introduce subtle issues, for instance, that the program should be modified in the style in which it is written.

Other online exercises include using the code in a larger application, or solving a similar problem. The advantages of rewriting reusable code are apparent in both activities.

Students can also be encouraged to create their own case studies. This activity reveals student thinking and helps instructors make sense of students' understanding of the material. Instructors can also incorporate the student solutions into subsequent course activities.

One other activity, that of solving the problem before seeing the solution and accompanying discussion, would seem to be good preparation for a case study. Students might be expected to be more sensitive to the decisions described in the narrative. Linn and Clancy [10] noted, however, that this approach was not always productive. Some students, having written one program to solve the problem, weren't interested in alternative.

There are many places in the program to insert bugs, such as off-by-one initializations and off-by-one or reversed comparisons.

Possible modifications of the programs include highlighting of holidays or other significant days, and printing weekend days in a special format. Code from the calendar programs can be reused in a variety of applications involving date computations, and in programs to produce different kinds of calendars. Examples of the latter are the Jewish, Muslim, Mayan, Chinese, and French Revolutionary calendars, and a fantasy calendar without Mondays.

One way to ensure that students have different types of expertise is to ask subgroups to study different case studies and then present the ideas to the rest of the class.

Discussion can also take advantage of previous online exercises. What were various ways of approaching these exercises? What aspects of the style and organization of the program made it easy or hard to modify? How does one set of test results provide better evidence for the correctness of the program than another? How did a partnership divide the problem, and how were the skills of the partners put to effective use?

Finally, discussion can provide opportunities for students to reflect on their own behaviors. The discussion leader might ask the group to compare their abilities to detect errors in output, to locate errors in code once they’ve been detected, and to find the simplest ways to fix the errors. Discussion might also encourage students to recognize and admit their programming weaknesses, such as propensities to "rush to the computer" or to test too much code at once.

Assessment
Learning to program well requires the acquisition of a number of subtle skills. The course objectives of ACM’s CS 2 [7], for instance, included the following:

• To continue developing a disciplined approach to the design, coding, and testing of programs written in a block-structured high-level language.

How can these skills be assessed? In the typical programming course, the end product of a programming assignment is graded rather than the supposedly "disciplined approach to design, coding, and testing" that created it. An exam is constrained by limits on the time available to take it and the time available to grade it. Exam questions tend to focus on isolated facts rather than on complex problems.

Case studies allow assessment of analysis, design, and development in the context of a challenging problem. Here are some example question patterns. They must, of course, be asked in the context of a particular case study.

Analysis

• Show where in the program a given variable can get a given value, and describe the circumstances under which this happens.
• Describe circumstances that would cause a given variable to have the same value as (or a greater or smaller value than) another given variable.
• Where in the program can the following condition arise?
• Suppose that a line of the program has been changed; the altered program then produces the following output. Does the output indicate a bug? If so, where might it be?
• Given the following output from the program, what was the input?
• The user types the following input to the program, and gets an error message. What could it have been?

Design and Development

• Suppose the program is to be extended to accomplish the following task. Which subprograms in the program should be changed, and how? In what sequence should the changes be tested and debugged, so that you would have the best chance of having a new improved version of the program working at all times?
• Suppose you wish to reimplement a given program data type as follows. Which subprograms should be changed, and how? In what sequence should the changes be tested and debugged?
• Which of the following changes to the program require modifying only one subprogram?
• Why test and debug one given procedure before another?
• Suppose that a line of the following procedure has been changed erroneously. Design a set of test data that would expose the error.
• Install consistency checks in the program.

Such questions, based on the context provided by the case study, are much less open-ended and much easier to grade than entire programs. They also require much less reading during an examination, since case studies can be reviewed in advance, than do questions in which a context must be set up from scratch. They therefore allow good programmers with reading deficiencies a better opportunity to display their knowledge.

The narrative description of design and development decisions is an important component for assessment. Linn and Clancy [10] found that students who received expert commentary did significantly better on their tests than students who received documented code without commentary.

Examples of assessment using the "Calendar" case study
The programs described in the "Calendar" case study, though each no more than two pages of code, provide surprising opportunities for questions about analysis, design, and development. Here are some examples.

Analysis

• Suppose that your lab partner, who is not so adept with the text editor, deleted a line in the program by accident, with the result that February in a non-leap year is printed with 1423 days. Where would you first look for the error?
• What small error in the program would produce output in which the first week of the month started a day too early and ended on Friday rather than on Saturday?
• Suppose that the LeapDay function were rewritten as follows. Is the revision equivalent to the original? If so, explain; if not, provide an argument to LeapDay for which the two versions return different results.
• During the output of which month(s) of 1986 would the variable startOfWeek have the value --3?

Design and Development

• Write a driver program that would allow you to test the PrintMonth procedure in isolation.
• Write a procedure for either version of the Calendar program that prints calendars for a user-specified number of years in a row.
• Suppose you wished to produce the output for each month by repeatedly filling a two-dimensional array with the appropriate dates, then printing it. Should the array elements be of type char or type integer? Explain.
• Describe what changes to the program would be necessary to make the modification just described.
• Suppose you wished the program to work for Julian years (pre-1582). Which subprogram(s) would have to be changed? Explain.
• Suppose that America implemented the four-day work week by eliminating Monday. Change the week-by-week version of the Calendar program to print months without Mondays. January 1986 (assuming it still started on a Wednesday) would then look as follows:

               January 1986 
             S  T  W  T  F  S 
                   1  2  3  4 
             5  6  7  8  9 10 
            11 12 13 14 15 16 
            17 18 19 20 21 22 
            23 24 25 26 27 28 
            29 30 31
  

Lectures
One might guess that lecturing about a case study would be difficult; the narrative description contains much of what a lecturer might wish to say about the problem solution. How, then, can a lecturer provide an interesting, enthusiastic presentation for students?

One good approach is to give suggestions about how to read the narrative and program: how to find the important parts, how to take notes on the program, what experiments to try, and what collection of input data should be built to test the program. The lecturer can also point out what programming patterns and good habits are illustrated in the case study, and relate them to students’ previous experiences in the class. In addition, the lecturer might enrich the problem solution by supplying missing information and structure for the students, and by adapting the material to their experience and background. Hints for the homework are an obvious source of material. Much of the published case study material discusses the design but not the development stage; the lecturer might present a model sequence for testing and debugging the program.

Another source of lecture material is extension of the ideas in the case study. A lecturer might discuss how segments of the program could be used for other problem solutions, or discuss problems that can be solved in ways illustrated in the case study. A lecturer might also talk about more general applications of case study activities. An example might be a technique like mutation testing, in which the goal is to build a test suite that catches standard types of errors intentionally introduced into the program (see Budd [3]).

Finally, the lecturer can personalize the presentation with his or her opinions about controversial aspects of the design or development. Discussion of the lecturer's personal experience with similar problems or approaches can fascinate a class.

Summary
As textbooks for CS 1 and CS 2 get thicker and thicker, are your students memorizing more and understanding less? Case studies allow students, guided by an expert, to explore and experiment with design, analysis, and modification of programs they might not be able to create on their own. Students can solve what seem like "real" problems by altering expert solutions. Instructors can assign homework, lab activities, and discussion topics related to real problems, and easily prepare examinations that both educate students and provide significant information about student progress.

References

     [1] Bentley, J., More Programming Pearls, Addison-Wesley, 1988. 

     [2] Bentley, J., Programming Pearls, Addison-Wesley, 1986. 

     [3] Budd, T.A. "Mutation Analysis: Ideas, Examples, Problems, and
         Prospects", in Computer Program Testing (B. Chandrasekaran and
         S. Radicchi, editors), Elsevier North-Holland, 1981. 

     [4] Clancy, M.J. and Linn, M.C., Designing Pascal Solutions: A
         Case Study Approach (working title), W.H. Freeman and Company, 
         1992.

     [5] Collins, A., Brown, J.S., and Newman, S.E., "Cognitive
         Apprenticeship: Teaching the Craft of Reading, Writing, and
         Mathematics", in Cognition and Instruction: Issues and
         Agendas (L.B. Resnick, editor), Lawrence Erlbaum, 1989.

     [6] Kernighan, B. and Plauger, P.J., Software Tools in Pascal,
         Addison-Wesley, 1981. 

     [7] Koffman, E.B., Stemple, D., and Wardle, C.E., "Recommended
         Curriculum for CS 2, 1984", Communications of the ACM, 
         August 1985, volume 28, number 8. 

     [8] Kruse, R.L., Data Structures and Program Design (second
         edition), Prentice-Hall, 1987. 

     [9] Ledgard, H. and Tauer, J., Pascal with Excellence:
         Programming Proverbs, Hayden, 1986. 

     [10] Linn, M.C. and Clancy, M.J. "Can Experts’ Explanations
          Help Students Develop Program Design Skills?", International 
          Journal of Man-Machine Studies, to appear. 

     [11] Linn, M.C. and Clancy, M.J., "The Case for Case Studies of
          Programming Problems", Communications of the ACM, to appear. 

     [12] Reges, S., Building Pascal Programs, Little-Brown, 1987. 

     [13] Van Wyk, C.J. (moderator), "Literate Programming" columns,
          Communications of the ACM (July 1987, volume 30, number 7; 
          December 1987, volume 30, number 12; December 1988, volume 31, 
          number 12;  June 1989, volume 32, number 6; and 
          September 1989, volume 32, number 9).