Pedagogical Patterns:
Successes in Teaching Object Technology

The process of training, retraining, and, most of all, educating people in object technology is an ongoing challenge which has many unanswered questions. While many good pedagogical ideas are presented at OO conferences and published in proceedings and journals each year, very little has been done to collate the effective practices of many OO educators into one publication. The purpose of the pedagogical patterns project is do just that, to create a publication which is similar to what Susan Lilly (in 1/96 Object Magazine) refers to as "reusable pedagogical design patterns."

According to Lilly, a pedagogical pattern should be repeatable and easy to adapt. Each pattern should be described in a way that allows it to be easily "instantiated" for different lessons by different instructors. However, patterns do not need to be new or original. Lilly compares this to the Gamma et al. "Design Patterns" book, as follows: "The largest contribution of the 'Gang of Four' book is the documentation of patterns that have been proven to work, not the invention of the solutions. What makes patterns useful is their ability to communicate proven solutions to common problems."

Most of the pattern ideas on this web page (many in first version) have been collected as part of three workshops held at ECOOP'96 (in Linz, Austria), TOOLS USA '96 (in Santa Barbara, California), and OOPSLA'96 (in San Jose, California). In addition, potential patterns were collected during a fourth workshop, held at the OT'97 conference this past April in Oxford, England. There was also a large amount of interest generated after a short Educators' Symposium presentation and Birds-of-a-Feather session held this October at the OOPSLA'97 conference.

The project leaders met at the end of November in Argentina to spend a week working on analyzing and categorizing the individual patterns, drafting a more useful format for the patterns, and making plans for the remainder of the project. The individual patterns are now being recast in a new format, a large task which is expected to be completed by early March. These newly drafted patterns will then be presented for review in mid-March at a patterns language conference (ChiliPLoP). In April, the fifth pedagogical patterns workshop will be held at the OT'98 conference in England.

From the feedback acquired from participants at the pedagogical patterns workshops and those who have provided feedback in other ways, a new format for the patterns has been drafted and is open for review. This format contains the following sections:

New "pedagogical pattern" ideas are always welcome. Individuals interested in contributing should email ideas to Mary Lynn Manns.

Project Leaders:

Mary Lynn Manns
University of North Carolina at Asheville
Asheville, North Carolina USA
manns@unca.edu

Helen Sharp
The Open University
United Kingdom
h.c.sharp@open.ac.uk

Phil McLaughlin
The Bloomsbury Software Company
United Kingdom
p.mclaughlin@soc.staffs.ac.uk

Maximo Prieto
Lifia - Universidad de La Plata
JP Morgan
Argentina
maximo@info.unlp.edu.ar

THE EVOLUTION OF A PEDAGOGICAL PATTERN

At the TOOLS'96 USA conference, participants in the "Challenges and Successes in Teaching OT" workshop created some drafts for pedagogical patterns by first generating a series of challenges, then brainstorming on the solutions to many of these challenges, and finally formatting a rough draft of pedagogical patterns for some of the challenges. An example follows.

I. One of the challenges is expressed:
Students experience interference from procedure-oriented concepts they already know. As a result, there is often more interference than reinforcing.

II. Potential solutions are brainstormed:
#1 The instructor can make comparisons for students.
#2 Or, the instructor can attempt to make students think in an object way from the beginning by postponing answers to students' inquiries regarding how their present knowledge (e.g. procedure-oriented) compares to OO.
#3 Or, the instructor may wish to lead students through the design of a system in first a "traditional" way and then in an OO way.

III. A pedagogical pattern is drafted from one of the three potential solutions:
Solution #3 was formatted into the first draft of a pattern, as follows:
1) Students design and implement a project using a traditional approach.
2) Instructor lectures on object concepts and suggests how this project could be repartitioned into objects.
3) Project is redone, by the students, using objects.

IV. The next step is to describe this pattern using the pedagogical pattern format. Since this was one of the first patterns contributed to this project, it is presently formatted in the old format.

NAME:
Design-Implement-Redesign-Reimplement (DIRR) Pattern

contributed by:
Steve Houk
Santa Barbara City College
Computer Science
721 Cliff Drive
Santa Barbara, CA 93109 USA
shouk@sisko.sbcc.cc.ca.us

INTENT
Explain new concepts and methods based on old concepts

MOTIVATION
It is often hard to get students to make the paradigm shift from functional programming to object oriented programming. The lecture-lab pedagogy provides a "concept" and "use" approach which can prevent the student from separating the "concept" from a specific "use". The DIRR pedagogy provides "relearning" methodology for reinforcing new concepts. In this pedagogy, the students are asked to design and implement programming solutions using their current paradigm. This is followed by a discussion of how the solution can be redesigned using concepts from the new paradigm. Finally, the students will reimplement their solutiona using the new paradigm concepts.

APPLICABILITY
Use the Design-Implement-Redesign-Reimplement pattern to bridge the gap from an old paradigm to a new paradigm.

STRUCTURE

Design: Students are given a programming problem and told to design a solution using their current familiar design methodology. The problem should contain components that can later be identified as redesignable in the new paradigm.

Implement: Students implement a solution to the programming problem using their current familiar coding methodology.

Redesign: After the students have implemented their solutions, the instructor leads a discussion of how the solution can be redesigned and repartitioned using new concepts from the new paradigm. Also presented are programming language features that support the new concepts.

Reimplement: The students redo the same programming problem using the new concepts from the new paradigm.

CONSEQUENCES: The DIRR pattern
1. Provides students with first hand experience of both the "old way" and "new way" of developing solutions.
2. Students gain practical insight into how new concepts relate their pre-established concepts.
3. Solving a problem more than one way often leads to deeper understanding of the concepts being addressed.
4. Questions arising from the students will tend to focus on the "why" things are done rather than on "how" they are done.

IMPLEMENTATION: Issues to consider
1. Double lab time required for each problem. However, second lab period should be shorter since many of the "semantic" issues have been handled by the students in the first lab.
2. Redesign discussions should center on how to repartition the problem and not on "good" previous solution.
3. Stronger (ego) students may be frustrated by having to "redo" their first solutions.
4. Evaluation should focus on reimplemented solution. However, ignoring first implementation entirely will reduce willingness of students to provide a wholehearted improved solution.

EXAMPLE INSTANCES OF THIS PATTERN
(Note: Although this "pattern" was conceived as a solution to the procedural-to-OO challenge mentioned above, it is defined in a general way so that it can have other instances -- so that it can be used in other lessons by other instructors (e.g. converting students from one operating system to another, one language to another, one development environment to another, etc.))

OTHER EXAMPLE PATTERNS

All the ideas on this page are presently in draft form. They still need quite a bit of work. Therefore, the project is soliciting feedback and ideas. Comments or further ideas can be emailed to Mary Lynn Manns.

The first group of patterns shown below is in the recently revised format described above. The second group is the collection of ideas in the older format (these are presently being redrafted into the new format).

PATTERNS IN RECENTLY REVISED FORMAT

NAME:
Reading, Critique, Lecture, Activity, Presentation with discussion (RCLAP) Pattern

originally submitted by:
Mary Gorman & Susan Burk
American Management Systems Training Services
300 Chapel Road
Manchester, CT 06040 USA
mary_gorman@mail.amsinc.com
susan_burk@mail.amsinc.com

INTENT:
To accelerate the learning of detailed modeling concepts and quality assurance techniques

IDEA:
This combination of elements will result in accelerated learning.

MOTIVATION:
The skills needed to build detailed, accurate and consistent OO work products can be difficult to pinpoint and learn. At times, the modeling effort may seem more like art than science. This pattern provides a means for an individual to initially assess his/her current proficiency (through reading and a critique of sample work products) and then offers a means to increase his/her proficiency through the exploration of additional detailed concepts (in the lecture, activity, and presentation portions).

APPLICABILITY:
The student must have a sound foundation in object-oriented analysis concepts (gained in a training environment or through detailed reading). In addition, students should have had at least four weeks applying basic OO concepts in a work environment. The pattern can be applied to a variety of OO models, such as the use case model, the object model, the state transition diagram, the object interaction diagram, etc.

CONTRAINDICATIONS:
None identified yet

STRUCTURE:

.Reading: Each student reads the course material independently. The material provides details on the type of model and its associated work products, a detailed explanation of the modeling concepts, steps in how to build the model, additional references and quality assurance guidelines. (AMS has organized the reading materials and job-aids in a handbook format, which serves as a ready reference for the students after the class. The OOA Analyst's Handbook focuses on three views: project management topics, practitioner needs and the quality assurance aspect of building models. The project management view is a summary of what to build, examples of the models and the roles and responsibilities. The practitioner's view provides details in how to build the models. The quality assurance view contains rules that define the object-oriented correctness of the models.)

.Critique: This individual activity requires the student to study a sample model and determine its completeness and correctness. The student uses the reading material as needed, especially the quality assurance guidelines, and considers how to fix/improve the model. Alternately the critique sample could be two options the student appraises to select the better alternative or if needed, to build a third model. It is an opportunity for the student to evaluate his/her proficiency to probe the details of a model, find problems, and define appropriate solutions.

.Lecture: In a group setting the instructor builds on the reading material, providing additional examples and explanations, engages the students in discussion, answers questions that may have been raised during the individual reading and critique activities and summarizes the students' critique findings.

.Activity: The students, in small groups, use the reading materials and other job-aids to build a model to fully explore the reading and lecture concepts. The instructor serves as a mentor to the teams. Each model reflects an aspect of a single case study. This case study is a common thread throughout the class. (The case study is also extended in other follow-on training courses.)

Presentation with discussion: Each group presents its results to the class. The other groups use the quality assurance guidelines to verify the results. Comparisons of the different results provide additional insights.

CONSEQUENCES:
Students take more active control of their own learning process. Students are provided with viable job-aids to use when back at work. Additional references in the reading provide students with pointers to material for further in-depth individual research as needed. The critique requires students to reference reading material to identify incorrect or inappropriate application of techniques. They become more familiar with the material through frequent referencing. The critique serves as a built-in test, enabling both the student and the instructor to assess the student's grasp of the concepts and to pinpoint areas needing additional instructional support. The common case study provides enhanced opportunities for the students to check consistency and completeness across models as well as within models.

ISSUES TO CONSIDER:
The reading material must be clear, descriptive, and well organized into appropriately-sized components without losing cohesion of the concepts. This material may be customized to a particular environment, e.g. a company. The material for the critique must be limited in scope, with the premises clearly stated. Yet the critique should challenge the students with complex variations of the modeling techniques. The critique examples must be carefully constructed to encompass the appropriate variations. One should not underestimate the amount of time needed to build the examples. The reading and critique portions could be done independently, prior to the course (but not so far in advance as to be forgotten). Thanks to the reading done by the students, the instructor can focus the lecture on more detailed explanations and examples. Occasionally, after critiquing the first model, some of the students express a preference for critiquing in a team setting. Those students can then critique in pairs or small teams, while allowing those students who would prefer to perform the critique on their own to work alone. Based on the students' critique results, the instructor may have to adjust the amount of lecture time to ensure the class understands the flaws in the sample models and the fixes required. The activity description must be well defined to exercise most of the modeling concepts that are presented in the reading component. The instructor should be prepared to seed the discussion during the presentation with appropriate questions. Some of the questions will be based upon typical student errors while the others will arise from the instructor's on-the-spot application of the quality assurance perspective to the students' models. The team activity can be customized to the students' specific business domain. This requires pre-delivery definition of the business area by the client and the instructor, to control scope.

CULTURAL DEPENDENCIES:
None identified yet

RESOURCES NEEDED:
Not recorded yet

EXAMPLE INSTANCES OF THIS PATTERN:
This pattern has evolved as we have shaped and re-shaped our Advanced Object-Oriented Analysis course yet it is not inherently restricted to object-oriented modeling training. It could certainly be generalized and applied to many other diverse training topics.

RELATED PATTERNS:
None indicated yet

NAME:
Mission Impossible

originally submitted by:
Alan O'Callaghan
Chair, Object Technology Group
De Montfort University
School of Computing Sciences
The Gateway
LEICESTER LE1 9BH
United Kingdom
aoc@dmu.ac.uk

INTENT:
The Mission Impossible pattern is used to make the student suspicious about their understanding of important OT concepts so that they continually question them.

IDEA:
Learners occasionally need to be "shocked" into deeper thinking about what they are doing in order to appreciate some of the subtleties. This is all the more necessary when such ideas as "objects model the real world" can be understood in an entirely naive way which disarms the learner in the face of real problems when they occur.

MOTIVATION:
A fundamental problem with teaching OT, whether it is in a 15-week lecture, tutorial and lab.-based course, or an industrial short course is that the educator is inevitably forced into a mode whereby abstracting and generalizing the subject into "key" concepts has the side-effect of oversimplifying a rich, deep technology which is full of subtleties. OT is, in software engineering practice, arguably concerned about "programming-in-the-large" and about the structure of software systems. It is difficult, if not impossible, to reproduce such systems (and therefore the problems they exhibit) in the classroom. Key truths about OT, that distinguish it as a paradigm from say "structured methods," are often given a naive expression (notoriously Meyer's "Objects are there for the picking" answer to the rhetorical question, "Where do I find the objects?"). This can lead to the learner badly underestimating the intellectual effort needed to master OO concepts. Students learn best from "hands-on" experience.

APPLICABILITY:
The pattern is best used selectively, after a logical block of learning in the form of instruction, lectures, reading and hands-on work has been encountered and conquered by the learner. The idea of the pattern is to present the learner with a problem that the basic concepts do not appear sufficient to solve, in order to provoke further questioning, exploration and self-study. It works best in group work situations. The pattern can also be used to form a link between the learning of basic and more advanced topics (the advanced techniques being needed to master the "impossibility" of the problem).

CONTRAINDICATIONS:
None explicitly identified, but misused, or overused, the pattern can destroy a learner's confidence in what she or he is learning. The pattern carries a health warning!

STRUCTURE:
A problem is presented which, at first look, seems to suggest a straightforward solution. A complete solution will, however, require careful consideration of a number of issues and will not normally be possible because: there is insufficient time to study the full range of issues thrown up, or there is insufficient information to complete the exercise, or no solution is possible despite first impressions The contrast between first impressions ("simple problem!") and the result of some study ("a deeper, more difficult problem than first we thought!") is crucial to the successful application of this pattern. A brief summary (5 mins. maximum) by the educator explaining why the problem was "impossible" is vital.

CONSEQUENCES:
If used appropriately, and successfully, the result is a wide-eyed learner keen to explore the deeper recesses of the technology and the philosophies which underpin it, including areas of controversy.

ISSUES TO CONSIDER:
The problem should be able to be presented in a short form, and yet be "complete" in the sense of there being sufficient information for the learners to begin their work There should be no more than 45 mins. work involved before the learners can appreciate that there are issues which require further explanation. There should be no need for a "final" solution to the problem. Indeed for the best implementations of it there is no solution. Closure comes with an understanding of the problem's "impossibility" not its solution. It is probably best, for reasons of learners' self-confidence, to sandwich the use of Mission Impossible between blocks of teaching which are aimed at delivering measurable competencies.

CULTURAL DEPENDENCIES:
None identified yet

RESOURCES NEEDED:
Not recorded yet

EXAMPLE INSTANCES OF THIS PATTERN:
This pattern is used in the teaching of a Final Year Object-Oriented Development module at DeMontfort University, Leicester, UK. The module aims at preparing students for the application of OT in the "real world" of commercial IT development where large-scale legacy systems and the issues surrounding them abound. Students take quite quickly to the idea that OT development is, in some sense, "seamless". Practical exercises reinforce the notion that objects identified in some conceptual model of the problem space can be mapped more easily into code than is the case with so-called traditional methods. This can lead to a naive confusion between "analysis objects" on the one hand, and code objects on the other. An exercise based on an anecdotal example in [Cook 1994] is used to disabuse students of these naive ideas, and to provoke discussion about the nature of the mapping between objects in various models (e.g., analysis model, design model, implementation model. The students are split into groups of 6-8 persons, given a scenario and asked to present an outline conceptual model (i.e., a modeling of the problem space), followed by a design model. The scenario is as follows: The sky is dark. The ground is cold. All is silent. The sun rises. The sky brightens. Birds sing. A cock crows. The ground is warmed. Grasses grow. Typically, students do not complete the first part of the exercise. They get bogged down because they attempt to apply concepts about program or code objects to their modelling of the problem. In particular, they attempt to discover "appropriate" methods and messages and apply them in a single-threaded chain of cause and effect which (though suitable and indeed necessary for a machine-based simulation) can only distort a real world problem which is full of parallelism and chaos. The educator can prompt fruitful discussion of the underlying issue (the difference between objects that model mental perceptions of the world and those that implement machine behavior) by posing simple questions in a timely manner: e.g., if a group has decided that the grasses grow because of messages being sent from the sun, ask in what order the messages are received and why the grass grows unevenly etc. By the end of the exercise, timed to fit into a one-hour tutorial, students realize that a relatively simple program (model the sunrise) becomes tortuous and difficult if a naive notion of object is applied in both kinds of model. Transformation is necessary. This is achievable by assigning responsibilities to objects in the analysis model until it is complete (in the sense of each analysis object's existence in the model being justifiable by some responsibility), and then assigning new responsibilities and reassigning responsibilities to fill in gaps in the causality chain in the design model, before identifying invocations to trigger actions to carry out the responsibilities. These invocation-responsibility mappings can then be further transformed into messages and methods which are programming concepts, not modelling concepts.

RELATED PATTERN:
Can be considered as a special variant of the Plan-Do-Reflect (PDR) pattern [Lilly, S. 1996. "Patterns for Pedagogy" in Object Magazine 1/96.]

NAME:
Incremental Role Play

originally submitted by:
Jutta Eckstein
ParcPlace Systems
Lochhamer Str. 11
80538 Muenchen
GmbH, Germany
je@parcplace.de

INTENT:
To clarify why a specific architecture was developed. To give the students a better understanding of complex software concepts.

IDEA:
Making the students behave as the objects involved in an architecture will help them understand it better.

MOTIVATION:
Educators often teach students solutions for problems the students never had. By explaining the problem first with an example out of the students world, they understand that there is a need for a solution to this problem. Often the solution seems to be very complicated at first glance, but it gets easier after using it several times. This approach is essentially right but it takes time. Since you normally don't have this time during a course, you could decrease the learning time by assigning object roles to the students.

APPLICABILITY:
This pattern has been used only in industry in one week courses, mostly at the very end of the week (students do have an understanding of objects). A less complex pattern (just the role play) has been used at the beginning of the week for explaining messages. As you can see from the Examples Instances section, the pattern has been used only in Smalltalk courses, but it should also work for other OO courses.

CONTRAINDICATIONS:
None identified yet

STRUCTURE:

. Problem statement: The instructor shows a problem out of the students world. If you don't have any in mind just take one in which the problem idea is easily grasped, e.g. you want to develop a UI-application. So you define some business objects and you want to view these business objects in different UIs for different users, e.g. take a bar chart, a pie and a table. You can interact with every kind of view, e.g. fill out the table, grow a bar with the mouse, etc. Every change in the view should change the model and every change of the model should be seen in every view. Almost everybody should understand that we need a mechanism which is responsible for this behaviour (hint: dependency).

. Lecture: The architecture or rather the concept is explained, so the students get an understanding of how the problem is solved. If we take the example from above, just explain which classes build the MVC framework and how the dependency mechanism works.

. Role Play: Every student plays one part of the concept for getting a deeper knowledge of the theory of the architecture. Students see how the different parts of the concepts are all working together to solve a bigger problem. So here we need at least one student acting as the model, one playing the view and one for the controller. Messages go back and forth by throwing a soft ball between the students.

. Lab: Students complete a lab prepared by the instructor where they figure out how the concept works. The instructions for the lab should be very detailed first with less detailed explanations while it's going on. For example, present the students first with a completed source example and let the students examine the code with the debugger. Now they can see how the messages are sent and implemented in the "real world". A more difficult example would be to let the students develop a small application for themselves.

. Discussion: This should be a student-centric discussion where the students recover what they have seen during the lab. The instructor leads the discussion towards the next problem (often the students come up with the problem for themselves). Staying with the MVC example, the students would probably state that MVC seems to be a rather complicated thing for developing just a small application, or believe that a lot of code has to be reproduced for every application. See, we have the need for the concept of ValueModels. As you can see in the discussion phase it's the responsibility of the instructor to "make" this pattern really incremental.

CONSEQUENCES:
This pattern:
- shows students why somebody has introduced a particular software concept. This means students understand the purpose of the concept.
- gives the students the opportunity to understand the concept from the inside by playing a role in the architecture.
- deepens the experience from the role game with a lab activity.
- should lead the discussion phase into the next problem statement, so it's easy to introduce the next, more complex, concept.

ISSUES TO CONSIDER:
- The problem statement should be enlightened from different sides, so that every student will be able to identify the problem from his/her own experience. Do not try to discuss different solutions, since the goal is to introduce a specific concept like MVC and not what else could have been developed. On the other hand, the students will get frustrated very soon if they see that their solution is not of much interest. To summarize:
- The problem statement is just an introduction to the concept.
- The lecture or theory itself should be as short as possible so one can begin role play as soon as possible.
- The game should be played very close to the reality. On the other hand, stuff which prolongs the game and is already clarified, should be omitted. For example method lookup mustn't be ruled out. The instructor shouldn't be afraid of playing the game. My experience is that, especially in industry, the students are happy if they get a less abstract explanation.
- The lab should lead step by step from more basic things in the concept to the more complex ones.
- The instructor must make the discussion lead to the next problem statement. For instance, go from MVC - ValueModel - AspectAdaptor to AspectAdaptor with subjectChannels.
- There is no experience about how this could work in a real huge group or at the university.

CULTURAL DEPENDENCIES:
None identified yet

RESOURCES NEEDED:
Not recorded yet

EXAMPLE INSTANCES OF THIS PATTERN:
This pattern has been used to teach:
- OO concepts, like sending messages
- Different patterns / architectures in Smalltalk
- MVC
- ValueModels
- AspectAdaptors
- AspectAdaptors using subjectChannels
(Hint for the role play: Simplify the architecture and use one student as the widget, one as the AspectAdaptor and one as the model. But the model sits on a subjectChannel, here on a chair. In this way you can change the model by placing a different student on the chair.)

RELATED PATTERNS:
- Physical Analogy
- Concrete to Abstraction Pattern
- The Three Bears Pattern could be used
- Role Play is used

PATTERNS IN OLDER FORMAT
(These are presently being recast into the new format described above)

Pedagogical Pattern #1
Concrete to Abstraction
(Version 2.0)
Ian Chai
University of Illinois
1304 West Springfield Ave.
Urbana, IL 61801 USA
chai@uiuc.edu

INTENT:
To keep students' interest when introducing them to their first patterns (or other abstractions.)

MOTIVATION:
Students taking their first OO class usually have never heard of patterns, and do not know what benefit they might derive from them. They may lose interest or get distracted before they understand what is going on.

Most readers of a book on design patterns already know that they want to learn a pattern. The reason they picked up that pattern was because they have read the summary and think it is relevant to their problem.

With a typical introductory classroom situation, however, students may not yet have this motivation. If we start by giving them a pattern name and then talking about the pattern, we could lose half the class before engaging their interest.

APPLICABILITY:
This pattern is mainly for use with students unfamiliar with the utility of patterns, or the domain of the particular patterns.

STRUCTURE:
Concrete:
Start with an example to which the students can relate. See Acquaintance Examples [Anthony] for suggestions on how to pick a good example. Abstraction: After you take the students through the example, then you can point out the aspects which can be applied in other instances. You can point out general principles, and then finally end up with describing the general pattern itself.

CONSEQUENCES:
This kind of presentation engages the students' interest and demonstrate the usefulness of the pattern before introducing the probably unfamiliar concept of patterns. Is not as good for a pattern catalog because it can take a long time to get around to the point. However, it keeps the students' interest better when they are unfamiliar with the problem.

After a few patterns introduced in this way, the students will start appreciating the power of patterns and become eager to learn the next pattern. At this point, you can then return to introducing them by name, motivation, and context.

IMPLEMENTATION:
Here is an example of using this pattern to introduce the Adaptor pattern [GoF]:

Concrete Example:
"One day, Maria's sink backs up. But she lives in a small town with only one plumber, a Vietnamese refugee named Tuan. Maria doesn't speak Vietnamese and Tuan's English is very poor. Fortunately,, Maria has a friend, Jim, whose family came to the USA with the fall of Saigon, and thus he knows both English and Vietnamese very well. So Jim translates for Maria and Tuan gets the job done, and everyone is happy.

"An analogous situation often happens in software. For example, Fred gives you a program that reads data from files using a File object. Mary gives you a HTTP client object that takes data from web pages.

"Now you want to modify Fred's program so that it can take data from web pages, but the protocols for the File object and the HTTP client object do not match. So you write a new object that sits in front of Mary's HTTP client object and presents a File object's interface for Fred's program.

"In this way, Fred's program can now read data from the web using Mary's HTTP client object.

"This kind of situation often comes up in OO when you have objects from different sources, which expect different protocols. It happens often enough that we've got a name for it: the Adaptor Pattern.

Abstraction:
"The Adapter Pattern tells you how to convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces. Here is a diagram of how it works...

RELATED PATTERNS:
Acquaintance Examples, Colorful Analogy [Anthony], Physical Analogy [Phil McLaughlin], Abstract to Concrete [not yet written: it says that once the students are familiar with the kinds of abstractions presented in class, you can then just present the abstraction first and they will already be motivated to see how to apply it -- this was suggested by someone during the Workshop]

EXAMPLE INSTANCES:
This pattern has been used to teach:
- Smalltalk programming course
- Design Patterns
- Mathematical abstractions

REFERENCES:

[Anthony]
Patterns for Classroom Education by Dana Anthony; PLoP '95
Proceedings http://st-www.cs.uiuc.edu/~chai/classroom-ed.html

[GoF]
Design Patterns by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides; Addison-Wesley 1995.
http://st-www.cs.uiuc.edu/users/patterns/DPBook/DPBook.html

==============================================================

The following two patterns are from Dana Anthony's paper "Patterns for Classroom Education". I am including them here because I refer to them in my pattern.
---------------------------------------------------------------

Acquaintance Examples

PROBLEM: How do you choose specific examples to use for a class?

CONSTRAINTS AND FORCES: There is a range of example domains, from those totally unfamiliar to those in which the student has professional expertise.

If a student is completely unfamiliar with an example's basis, the instructor can spend more time explaining the example than using it. If the instructor is trying to demonstrate the creation of abstract classes, and uses as the example "Control Chart", which has as concrete subclasses "Non P Control Chart" and "X Bar Chart" among others, he doesn't want to spend more time explaining what X Bar means than what the difference between abstract and concrete is.

On the other hand, if the student is an expert in the example domain, the student can become bogged down in the example's domain details, and fail to see the point the example was intended to illustrate. If the instructor is trying to explain when to use a Phone Number object instead of an array of strings representing the area code, exchange, and station of a phone number, she doesn't want the telephony expert student arguing whether exchanges are a valid description of how phone numbers work these days.

SOLUTION: Choose examples that are the most likely to be familiar to students, but not to be within the area of students' expertise. One way to do this is to choose businesses that students patronize but don't run, for instance a hotel or a video rental store. You may wish to have two alternatives ready so you can use the one which is more appropriate for each group of students. Choosing appropriate Acquaintance Examples can be a very difficult task.

If a class is homogeneous, with all students having expertise in the same domain, an Acquaintance Example can serve as an "ice-breaker", to get students to see how to apply their new knowledge. Then the instructor can supplement the Acquaintance Example with an example closer to the students' domain, to demonstrate that their new knowledge applies to their domain of expertise as well.

--------------------------------------------------------------

Colorful Analogy

PROBLEM: A concept which is very important has a lot of boring, detailed ramifications. It is not suitable for a simulation game, and is easily forgotten until it becomes a problem and causes trouble.

CONSTRAINTS AND FORCES: This is a concept whose name may be memorable but the explanation is not. People may tend to remember that there's something called that, but they forget what it means. Simply emphasizing this concept tends to just confuse people, or to be so boring that students will just tune out.

SOLUTION: A dry concept can be highlighted with a colorful analogy that provides a place to go back to recall the details.

The example I see most frequently using the colorful analogy is the explanation of the difference between identity and equality in objects. The analogy is a story of a restaurant patron who sees another diner eating a delicious-looking lasagna. He tells the waiter, "I want what she's having." Equality would mean the waiter goes into the kitchen and gets another plate of lasagna for him. Identity would mean that the waiter takes the lasagna the other customer is eating, and gives it to him. With the right analogy, a single word (in this case, "lasagna") can become a touchstone that recalls enough of the details of the explanation to make sense.

Pedagogical Pattern #2
Reading, Critique, Lecture, Activity, Presentation with discussion
RCLAP Pattern
(See above in group of patterns in newly revised format)

Pedagogical Pattern #3
Lecture-Examples-Activity-Student Presentation-Evaluation
(Version 2.0)
Martin L. Barrett
Department of Computer and Information Sciences
East Tennessee State University
Box 70711
Johnson City, TN 37614-0711 USA
barrettm@etsu.etsu-tn.edu

INTENT
To introduce class modeling.

MOTIVATION
Few students in an introductory class have experience with data modeling. When presented with a modeling task, their main problem is where to begin. Some introductory instruction followed by group work and evaluation can provide a framework for modeling.

APPLICABILITY
The pattern is used to introduce class modeling. It can be reused as students gain more experience for high level program design and implementation.

STRUCTURE
Lecture: An overview of class modeling using language-based recognition techniques, followed by ratings of importance and by classification, is given in a short lecture. Natural language-based recognition translates certain parts of speech into candidate classes, objects, methods, and attributes.

Examples: Several example analysis models are done with the whole class, with discussions of other possible choices and rationales given for the decisions made. Brainstorming is used for data gathering, followed by analysis, and finally an evaluation of the proposed solution. This method is based on entity-relationship modeling as done in the Shlaer-Mellor methodology.

Repeated Activity: Students work in a small group setting. Several analysis problems are used. Each consists of requirements statements for a real world problem. The group must work out a reasonable class structure with the methods used in the examples. Again, emphasis is on brainstorming for the data and the proposed class structures. As students gain experience with the method, more complicated problems using more complex class relationships can be used.

Student Presentation: One student from each group presents her/his group's solution, including justifications for each decision. Only one sample answer to each problem is given unless a group feels its answer is significantly different from the presented answer. Students analyze and critically evaluate the proposed solutions.

Evaluation: The entire class, led by the instructor, discusses each solution and suggests possible alternatives. The following are among the points to evaluate: the translation from words to OO entities; the relative weighting of importance of the entities; the relationships among the entities; the level of detail of the model; and the feasibility of the proposed solution.

CONSEQUENCES
This pattern:
1. Gives students a low-risk method for proposing solutions to analysis problems through brainstorming and repeated problems.
2. Emphasizes analysis as a group activity.
3. De-emphasizes implementation as the main programming activity.
4. Provides students with opportunities to present and defend their work.
5. Exposes students to other's solutions and thoughts on similar problems.

IMPLEMENTATION
1. Instructor needs to encourage full participation in group activities.
2. A good set of problem specifications must be developed. They may include non-computing real world problems. However, their scope should remain small enough to be tractable.

3. Class time for this activity must be allocated from other activities; in particular, this activity, as will most small group activities, will take more time relative to the outcomes gained than lecturing on the same material.

4. The activity's emphasis is on data modeling and class/object relationships at the expense of modeling control, timing, and algorithms. Other activities must be used to cover this material.

EXAMPLE INSTANCES OF THIS PATTERN

This pattern has been used to teach
1. Introduction to OO concepts
2. OO analysis
3. OO design.

RESOURCES NEEDED
None.

RELATED PATTERN
LASD

Pedagogical Pattern #4
Brainstorming Pattern
(Version 2.0)
David Bellin
North Carolina A&T State University
Greensboro NC 27411-0002 USA
dbellin@ncat.edu; dbellin@acm.org

INTENT
To introduce organizational techniques CRC analysts use to discover classes.

MOTIVATION
Students in CS programs often have a difficult time applying group interaction techniques. This is because typical instruction, even that which uses group projects, does not simulate many industry meeting situations. Brainstorming techniques based upon social psychological research have been proven effective when applied in a specific fashion by OO analysts in discovering classes in a new system.

APPLICABILITY
The Brainstorming pattern introduces a key technique used in CRC Card Analysis.

STRUCTURE
Step 1: Review Brainstorming Principles:
All Ideas Are Potential Good Ideas
Think Fast and Furious First, Ponder Later
Give Every Voice a Turn
A Little Humor Can Be a Powerful Force
Step 2: State Session Objectives
Step 3: Use a Round Robin Technique
Step 4: Discuss and Select Candidate Classes

CONSEQUENCES:
The brainstorming pattern:
* provides a method for early discovery of candidate classes in a new system
* encourages students to recognize the importance of group interaction in early analysis stages
* lets instructors make the class discovery process tangible
* may be resisted by technology oriented students who view people skills as peripheral or time consuming

IMPLEMENTATION
* exercises can be difficult to implement if the available population is not diverse
* many references are to literature outside of computer science (but see "The CRC Card Book" by Bellin & Simone (Addison-Wesley)
* instructors with industry experience are likely to have more success with this pattern
* flipcharts and markers are essential aids to the process
* don't criticize ideas; don't laugh at other participants suggestions
* one person must serve as the scribe (whoever writes the fastest!)
* pattern excludes revision of candidate classes (see related Role Playing pattern)

Related Pattern
* Role Playing Pattern
* Three Bears Pattern (when you don't know where to go next)
* Round Robin Pattern

Example Instances of this Pattern:
* used to teach class discovery in applications including:
* stock market
* ATM machines
* traffic light control

Pedagogical Pattern #5
Role Playing Pattern
(Version 2.0)
David Bellin
North Carolina A&T State University
Greensboro NC 27411-0002 USA
dbellin@ncat.edu; dbellin@acm.org

INTENT
To introduce organizational techniques CRC analysts use to refine a list of candidate classes and begin to model object interactions.

MOTIVATION
Students in CS programs often have a difficult time applying group interaction techniques. This is because typical instruction, even that which uses group projects, does not simulate many industry meeting situations. Role Playing techniques based upon social psychological research have been proven effective when applied in a specific fashion by OO analysts in refining the preliminary classes in a new system from a candidate list to a core list of classes.

APPLICABILITY
The Role Playing pattern introduces a key technique used in CRC Card Analysis, after a team brainstorms and creates a list of candidate classes. Assumes knowledge of CRC cards and scenarios.

STRUCTURE
Step 1: Create List of Scenarios
Step 2: Assign Roles
Step 3: Rehearse Scenarios
Step 4: Correct CRC Cards and Revise Scenarios
Step 5: Repeat Steps 3 and 4
Step 6: Perform Final Scenarios

CONSEQUENCES
* makes class interactions concrete
* is a demonstration of object anthropomorphism in action
* provides a method for early refinement of core classes
* encourages students to recognize the importance of group interaction in early analysis stages
* lets instructors make the class discovery process tangible
* may be resisted by technology oriented students who view people skills as peripheral or time consuming

IMPLEMENTATION
* exercises can be difficult to implement if the available population is not diverse
* many references are to literature outside of computer science
* instructors with industry experience are likely to have more success with this pattern
* small groups facilitate pattern utility (6 persons ideal)

RELATED PATTERN
* Brainstorming Pattern (to create candidate class list)
* Three Bears Pattern (to free group to explore new ideas when stuck)

EXAMPLE INSTANCES OF THIS PATTERN
* used to demonstrate class refinement in applications including:
* stock market
* ATM machines
* traffic light control
See also "The CRC Card Book" by Bellin & Simone (Addison Wesley), for more examples and details.

Pedagogical Pattern #6
Round Robin Pattern
(Version 2.0)
Kent Beck & David Bellin
70761.1216@compuserve.com
dbellin@ncat.edu; dbellin@acm.org

INTENT
One of the most difficult aspects of team work is getting everyone in the room to work on equal footing. Both organizational differences (jobs, position, etc.) and personality can quickly and inadvertently lead to a core of speakers and a core of listeners. Moreover, the fact that the listeners are not talking does not mean they are not thinking or that they are in agreement. The best way to avoid this dynamic is to use a round robin technique to solicit suggestions.

MOTIVATION
Students in CS programs often have a difficult time applying group interaction techniques. This is because typical instruction, even that which uses group projects, does not simulate many industry meeting situations. Role Playing techniques based upon social psychological research have been proven effective when applied in a specific fashion by OO analysts in refining the preliminary classes in a new system from a candidate list to a core list of classes.

APPLICABILITY
The Role Playing pattern introduces a key technique used in CRC Card Analysis, after a team brainstorms and creates a list of candidate classes. Assumes knowledge of CRC cards and scenarios.

STRUCTURE
For example, if you are trying to develop a list of possible classes for a system, go around the table. As each member of the team contributes an idea, write it down on the board. The facilitator should do the writing since the other members of the team should be watching and thinking. If there is a team member who does not have enough information on a particular problem to contribute to the brainstorming, that person can act as scribe as a way to keep them involved, but, if a team is chosen well, every member should be an important source of possible classes. The goal of the round robin is to allow the group to move ahead at an even tempo but to give people enough time to think. Short pauses are fine, but breaks of more than 60 seconds can interrupt the momentum and ideas may be lost. To keep things going you can establish a "pass" policy. If someone is really stumped, they can "pass" for that round, but they should take their regular turn the next time around. The facilitator needs to be sensitive here. If someone is slower to speak, don't cut off their turn too soon. At the same time, keep things moving so that other people do not forget what they want to say. The brainstorming is complete when everyone in the group has to pass.

CONSEQUENCES
* provides a method for early refinement of core classes
* encourages students to recognize the importance of group interaction in early analysis stages
* lets instructors make the class discovery process tangible
* may be resisted by technology oriented students who view people skills as peripheral or time consuming

IMPLEMENTATION
* instructors with industry experience are likely to have more success with this pattern
* small groups facilitate pattern utility (6 persons ideal)

RELATED PATTERN
* Brainstorming Pattern (to create candidate class list)
* Twelve Bears Pattern (to free group to explore new ideas when stuck)
* Role Playing Pattern (for refining core class interactions)

EXAMPLE INSTANCES OF THIS PATTERN
* used when implementing several other patterns.

Pedagogical Pattern #7
Incremental Role Play
(See above in group of patterns in newly revised format)

Pedagogical Pattern #8
Lab-Discussion-Lecture-Lab (LDLL) Pattern
(Version 1.0)
Mary Lynn Manns
Univ. of North Carolina at Asheville
Computer Science Department
Asheville, NC 28804 USA
manns@unca.edu

INTENT
Introduce software concepts.

MOTIVATION
Students often have a difficult time understanding software concepts which are introduced in a classroom lecture format. This is because the lecture-lab pedagogy utilizes a "this is what will happen when you do this" approach which can be too abstract to provide a foundation for learning software. The LDLL pedagogy offers an alternative approach. It begins with an introductory step-by-step lab, follows with a discussion and an explanation of what the students did, and then reenforces the concepts with a more advanced lab.

APPLICABILITY
Use the Lab-Discussion-Lecture-Lab pattern to introduce a software tool and/or concepts in a programming language.

STRUCTURE

Lab:
Students complete a step-by-step lab, prepared by the instructor to introduce the software concepts. This lab must have detailed written instructions and include questions which encourage students to record and analyze what they see on the screen as they proceed through the exercise.

Discussion:
After the lab is completed by each student, the instructor leads a student-centered discussion of the following:
- the concepts which were unfamiliar to the students as they completed the exercise
- any problems the students encountered (in order to quality control the exercise for future use)

Lecture:
Instructor lectures on the new concepts which were introduced in the lab, with continuous references to the experiences the students had while doing the lab.

Lab:
Students complete a more complex lab exercise which reenforces and examines each student's comprehension of the new concepts.

CONSEQUENCES
The LDLL pattern:
- allows students an active involvement in their learning by introducing them to new concepts as they are using the software
- encourages students to record, and to reflect upon, what happened when they were involved in their learning
- enables instructors to give more concrete, less abstract, lectures
- requires additional work on the part of the instructor to prepare the detailed instructions in the first lab
- may take longer than a lecture-lab pedagogy; however, the increased level of student comprehension seems to decrease the necessity for extensive follow-up and review periods

IMPLEMENTATION
Issues to consider:
- Lab exercises can be short (covering one or two concepts) or lengthy (covering many concepts). Short lab exercises can be completed during a designated lab period; for more lengthy labs, it is recommended that they be assigned and completed outside regular class hours.
- Since students will be exposed to the new concepts for the first time during the first lab, this lab should be written in a detailed, step-by-step manner and include references to documentation and/or textbook pages where clarification may be obtained.
- The questions which appear throughout the first lab exercise should allow the students to analyze what they enter and what they see on the screen. These questions will then serve to stimulate and lead the discussion session.
- Instructors will find that the lecture session, since it is given after the lab and discussion sessions, will require a much shorter period of time than lectures given in a lecture-lab format.
- The follow-up lab should require analytical skills and test the student's understanding of the concepts. Unlike the first lab, it should be evaluated by the instructor.

RELATED PATTERN
(none so far)

EXAMPLE INSTANCES OF THIS PATTERN
This pattern has been used to teach:
- The Smalltalk environment
- Smalltalk programming concepts
- C programming concepts
- BASIC programming concepts
- Fortran programming concepts

Pedagogical Pattern #9
Lecture-Activity-Student Presentation-Discussion (LASD) Pattern
(Version 1.0)
Helen Sharp
The Open University
Computing Department
Milton Keynes MK7 6AA
United Kingdom
h.c.sharp@open.ac.uk

INTENT: To give students a deeper understanding of a concept or set of concepts.

MOTIVATION: When first introduced to a concept, a students may come to understand it from only one perspective. This pattern allows students to deepen their knowledge through exposure to other students' experiences and perspectives.

APPLICABILITY: This pattern has only been used in a revision context, i.e. students have completed the bulk of the course, and are revising for the examination.

STRUCTURE:
Lecture: This summarisies the topic being covered, pulling out and highlighting the key concepts and techniques.
Activity: A group (preferrably) or individual activity to exercise the concepts with the tutor acting as facilitator if necessary.
Student Presentation: One member of each group, or each individual, presents their results from the activity, being encouraged to express any uncertainties, and points of disagreement or high level of discussion.
Discussion: Students discuss the differences in results, comment on areas of uncertainty and disagreement, and what they have learned through the activity itself, and from hearing others' results.

CONSEQUENCES: The LASD pattern:
1. Provides the tutor with the opportunity to summarise key points in an area;
2. Provides practice for students in exercising a concept or set of concepts within a supported environment (not necessarily the case when working in a distance education setting).
3. Compels students to clarify their thoughts for the presentation to fellow students and the tutor.
4. Deepens the learning potential by sharing other students' experiences: misconceptions and breakthroughs.
5. Invites students to reflect on what they have learned.

IMPLEMENTATION: Issues to consider:
1. The activity needs to be deep enough to engage the students and not to simply re-state the key concepts given in the lecture.
2. The tutor needs to keep a relatively low profile and allow students to learn from each other.
3. Students and teams will complete the activity at different times. It is worth considering allowing teams to swap about and help each other while waiting for all groups to finish. This increases the level of cross-fertilization.
4. If this is used in a revision setting, then it allows more time to look at deeper issues, since students are already familiar with the topic.

EXAMPLE INSTANCES OF THIS PATTERN
This pattern has been used to teach:
- OO analysis
- OO design
- Smalltalk programming

RELATED PATTERN: (none so far)

Pedagogical Pattern #10
Programming in the Tiny, Small, Large (TSL) Pattern
(Version 1.0)
Billy B.L. Lim
Illinois State University
Applied Computer Science Department
Normal, IL 61790 USA
bllim@ilstu.edu

INTENT
To introduce software concepts, especially those that require a number of iterations for various depths.

MOTIVATION
When introducing new software concepts, it is often the case that the students do not completely grasp the concepts until they get to practice the concepts in some programming exercises. This is especially true when introducing object-oriented concepts to students who have seen only the procedural paradigm. Experience shows that the paradigm shift that has been so widely talked about can really make the learning of objects very difficult.

The pattern of pedagogy described here stresses the importance of a 3-stage reinforcement of the lectures presented in class. The three stages, detailed in the STRUCTURE section given below, permit an instructor to monitor the students' progress in a topic-by-topic basis, to test if the students can combine the topics and apply them in a larger setting, and to solve a "real-world" problem using all concepts discussed (and thus seeing the "big picture"), respectively.

It should be noted that the use of this pattern, in part or as a whole, is not a revolutionary concept. This discussion merely emphasizes the importance of carrying out the pattern (all three parts of it!) in a consistent manner as the author's experience shows that if any of the three is not practiced consistently, the learning of an already difficult subject matter can be made even more difficult.

APPLICABILITY
The TSL pattern can be used to introduce any software concepts, whether they are programming related or not. The examples used in this article just happen to be related to object-oriented programming.

STRUCTURE

Tiny:

This part involves setting up homework assignments that typically take only a few days to complete. (More accurately, students are given only a few days to complete. The work itself should only take a little while.)
This type of assignments permits the instructor to reinforce materials taught in class and more importantly, get immediate feedback from the students so that further clarification and/or elaboration of the materials may be given. Multiple questions may be assigned in a homework of type "tiny," each focusing on a specific topic of interest.
Examples of "tiny" assignments include simple class definition with data and behaviors, exploring the difference between private, public, and protected access control (for C++ only), using self and super pseudo variables (for Smalltalk only), and testing the effect of including/excluding the keyword virtual when defining member functions (for C++ only).

Small:

Assignments of type "Programming in the Small" represent those that are do-able in weeks rather than days, unlike those of type "tiny." This type of assignments allows an instructor to give a more in-depth study of certain topics that are deemed central to the course. This next step, which can be a much more elaborate one, is a natural progression after the students have had a chance to learn the individual topics with the "tiny" assignments.
An example of a "small" assignment is one that involves the development of one or more classes with a fair number of responsibilities in a class library. For instance, students may be asked to develop a string class that supports 10-20 responsibilities. This will allow the reinforcement of multiple ideas discussed in lectures such as class definition, operator overloading, the danger of using default assignment operator (if using C++), constructors (if using C++), etc.
Another example, one that may be appropriate for introductory students (e.g., CS1), involves designing and implementing a calculator. If the students are initially exposed to the procedural paradigm first, then a procedural approach to this problem will involve functional decomposition of the calculator features, with each feature implemented in a function.
Then the students may be asked to re-do the calculator assignment but this time with the notion of a calculator object that is responsible for all those features implemented before. With this, the students can compare and contrast the two approaches and see the similarities and differences. They may also be asked to extend, through inheritance, the original calculator with more functionality.

Large:

This part involves a comprehensive term project that spans the entire semester. This all- encompassing project, which consists of several milestones, allows the students to apply all the concepts studied in class and enables them to see the "big picture" through the development of a "real-world" application. The milestones involved may include proposal, CRC cards, use cases, object diagrams, class definitions, GUI design, prototype, full implementation, etc. depending on the type of courses being offered.
An example of a project for a junior/senior level course is the development of an application that makes use of certain class libraries that are made available to the students. These libraries are typically GUI and/or foundation classes based. The application might also involve the creation of several new classes by the students themselves. Typically, these new classes are very much domain specific (e.g., Policy class for an insurance application, RentalItem class for a rental application, etc.).

CONSEQUENCES
- The TSL pattern allows students to see not only the forests and the trees, but also the "leafs" within individual trees. They can grasp abstract concepts early in the course through "tiny" assignments before they embark on a more challenging one. This reinforcement, while tiny, is often overlooked by many educators and thus students are left making a "large" jump while they are doing an assignment that is thought to be "small" by the instructor.
- With TSL, a three-prong reinforcement is established and students are actively, constantly, and progressively participating in class activities. This type of student involvement makes the learning fun and keep the students' interests on the topics high.
- Then, with the "small" and "large" assignments, students get to see and eventually appreciate the beauty of object-oriented technology. Having worked on the individual pieces and having combined those pieces together give them the "big picture" and the "ah- huh" feeling that every student should feel after completing the course.

IMPLEMENTATION: Issues to consider:
- One of the most important issues when implementing the TSL pattern is time management. With the "tiny" part, students are given a "tiny" assignment almost every week. In a course that meets three times a week, say Mondays, Wednesdays, and Fridays, a homework may be given on a Monday and it is due back on the Friday of the same week. The Wednesday in between may be used to clarify homework requirements if needed. That amounts to approximately 12-14 "tiny" ones and that can be exhausting for both the students and the instructor. A partial solution (for the instructor) might be to grade only a portion of the assignment and discuss the non-graded ones in class. Students would have done (or at least thought about) the problem sets and that makes the discussions easier to follow. As for the students, the number of assignments can be relaxed a little bit if the students are following the materials well.
- For the "small" assignments, approximately 4-5 may be given in a 16-week semester. This gives the students sufficient time to devise a solution (which should be a major part of the total time), learn the development environment (since "tiny" assignments may not require the use of a computer), implement the solution, clean up their code, and provide a solid documentation for their work.
- As for the "large" assignment, there is only one since this is a term project. Depending on the level of the course, a team consisting of two, three, or four may be formed by the instructor or the students themselves. Much like group projects in other courses, students will be asked to report on group activities, perform self-evaluations, hold regular meetings, and give final presentations. This typically takes up a lot of the students' time and hopefully they learn to delegate work and to be responsible for work assigned to them. Otherwise, they will see that they cannot complete the work by themselves or that the pieces do not come together when they are combined at the end of the semester.

EXAMPLE INSTANCES OF THIS PATTERN
This pattern has been used to teach:
- Smalltalk Programming
- C++ Programming
- OO Analysis and Design*
- database design*

*Even though this pattern is called "Programming in the Tiny, Small, Large (TSL)," it is general enough for one to use it in analysis, design, and many other things, whether they are computer-related or not.

RELATED PATTERN
The individual components in LDLL (Lab-Discussion-Lecture-Lab) pattern.

Pedagogical Pattern #11
Explore-Present-Interact-Critique (EPIC) Pattern
(Version 1.0)
Jorgen Lindskov Knudsen
Ole Lehrmann
Aarhus University
Computer Science Department
Ny Munkegade 116, DK-8000
Aarhus C, Denmark
jlknudsen@daimi.aau.dk
olmadsen@daimi.aau.dk

INTENT:

To give the student the ability to learn in the future, and to share knowledge with the other members in a project group.

MOTIVATION:

Two of the most important ability of successful software developers is (1) to be able to learn new material efficiently, and (2) to be able to share knowledge and insights with the other members of the work group.

This pattern allows the students to acquire these abilities by forcing them into being the teachers for themselves.

APPLICABILITY:

This pattern have only been used in courses at the Master's level. Whether applicable at other levels is not know. This pattern is used as the primary (only) educational pattern for entire semester courses. This pattern have been used for at least 10 years in many different courses.

The pattern is usually instantiated for groups of 2-3 students. It have also successfully been used for individual students. Student groups with more than three students are usually not successful.

STRUCTURE:

The pattern is instantiated by the students being handed (or they have voluntary chosen) a subject matter (e.g. Garbage collection, Multiple inheritance, Attribute Grammars, The Eiffel Language). They are also handed some materials (papers, book chapters, etc.) on the subject matter (or a list of references to such materials).

The pattern then consists in four major parts, which are more or less sequential:

1) Explore: Here it is the obligation of the students to gain an insight into the subject matter. In most cases, sufficient insights cannot be gained from the materials, and it is the students' responsibility to seek further materials (by tracking references from the materials, seeking further materials at the library, or elsewhere). In this phase, the Lecturer offers assistance in understanding the difficult parts of the materials, and by giving pointers to other, possibly interesting materials on the subject matter.

This exploration phase is usually 2-3 weeks.

2) Present: Here the students are expected to prepare a lecture for the other students in the course on the subject matter. The quality of the lecture is expected to be comparable to the lecture, the Lecturer would otherwise have been giving. Emphasis is put on clarity of presentation and especially the ability to present the essentials of the subject matter.

The lecture is usually 2x45 min.

3) Interact: Immediately following the lecture, the entire course discuss the subject matter, guided by the students responsible for the subject matters (i.e. they must have prepared this discussion phase). In this phase, it is important to make comparisons with the other subject matters, that might have been presented previously in the course (or in some cases, those that will follow later on in the course).

This interaction phase is usually approx. 30 min.4) Critique: Immediately following the interaction phase, the entire process is discussed. The students responsible for the subject matter give their evaluation of their work, and the rest of the students in the course offer critique (positive as well as negative) on (1) the preparation, (2) the presentation, and (3) the discussions.

This critique phase is usually 5-10 min.

The pattern is used repeatedly within the same course. The entire course is organised as a sequence of instances of this pattern. These instances are active, overlapping in time (more later).

Each week, one pattern instance is active in the lecture time of the course. This implies that the presentation, interaction and critique phases are conducted in the lecture time of the course.

Each pattern instance is active for approx. one month (depending on the students).

CONSEQUENCES:

The EPIC pattern:
1. Provides practice for students to learn by themselves 2. Provides practice for students to present material to pears (sharing knowledge)
3. Provides practice for students to give and receive critique to and from pears.
4. Compels students to focus on essentials rather that details when approaching new subject matters.

IMPLEMENTATION:

Issues to consider:
1. The subject matters needs to be chosen to match the capabilities of the students in the course.
2. The sequence of subject matters presented in the course should be planned ahead at enable interesting comparisons during the course. Especially important is to plan for possible contradicting conclusions in the different subject matters (to spin off discussions in the group).

RELATED PATTERN: (none so far)

EXAMPLE INSTANCES OF THIS PATTERN:

Please note, that this pattern is targeted towards being used as the overall pattern for an entire course. The following is a list of subjects, that were covered in the last course, where this pattern were used repeatedly.

Subjects:
Week 0: Introduction to the course
Week 1: Introduction to Smalltalk
Week 2: Introduction to C++
Week 3: Introduction to Eiffel
Week 4: Introduction to CLOS
Week 5: Introduction to Self
Week 6: Multi-methods in OO languages
Week 7: Constraint OO Programming
Week 8: Concurrent OO Programming
Week 9: Distributed OO Programming
Week 10: Introduction to CORBA, SOM, etc. (* hand-in of group reports *)
Week 11: Persistence and OO Databases
Week 12: OO Analysis and Design
Week 13: Evaluation of course and discussion and evaluation of group reports

In this instance, the students were required to supplement their presentations with a small written report on the subject matter (5-10 pages). This report were presented, discussed and evaluated (nograding) in the last week of the course (jointly by the teacher and the students).

The hand-outs for each subject was 2-4 papers (or book chapters). Details on the contents of these hand-outs can be obtained from us.

SPECIAL RESOURCES NEEDED:
The EPIC pattern does not demand any specific resources.

Pedagogical Pattern #12
"What did you eat for breakfast?" Pattern
(Version 1.0)
Karen Karaim Brown
ObjectSpace
kbrown@objectspace.com

INTENT
To teach the use of accessors and mutators for accessing an object's private data.

MOTIVATION
Students have difficulty remembering to use accessors and mutators (i.e. getters and setters) to retrieve and modify an object's data. It is useful to illustrate that to avoid doing so is dangerous to the object's health, and hence to the application. The WDYEFB pedagogy provides a somewhat graphic, physical metaphor that will clarify the proper use of accessing methods and make students gulp when reminded of the althernative.

APPLICABILITY
Use the What Did You Eat For Breakfast pattern to reinforce the use of accessors and mutators.

STRUCTURE
- The instructor asks a student (named Greg for purposes of illustration here), "Greg, what did you eat for breakfast?". Greg answers, say "A bagel and coffee." The instructor points out that Greg'spublic interface has been properly invoked, and Greg is induced to answer in an acceptable format, while hiding his implementation.
- The instructor then describes that the visceral alternative is tipping Greg's head back, shoving one arm arm down his throat and grabbing a piece of the bagel. That violates the privacy of Greg's data, bypassing his public interface. (Note: while it may be more palatable to some to slice the student's stomach open to determine its contents, you don't want to kill the object.)
- Obviously, it is equally hard for Greg to obtain or modify this information without also using accessing methods.
- Throughout the class, anytime a student attempts to bypass using accessors and mutators, the insturctor need only remind them that they are reaching down Greg's throat.

CONSEQUENCES
The WDYEFB pattern:
- concretely emphasizes the private nature of an object's data - grosses students into using accessors and mutators

IMPLEMENTATION
Issues to consider:
- This pattern has only been used in classes whose students have already demonstrated a sense of humor, however slight.
- If groans and looks of disgust are the only responses, the instructor may want to avoid reiterating it later, although the reminder is not quite so graphic and may be more palatable.

RELATED PATTERN
(none so far)

EXAMPLE INSTANCES OF THIS PATTERN
This pattern has been used to teach:
- accessing methods in Smalltalk

Pedagogical Pattern #13
Design-Do-Redo-Redo (DDRR) Pattern
(Version 1.0)
Marcelo Jenkins
Department of Computer and Information Sciences
University of Costa Rica
P.O. Box 025216
Miami, FL 33102 USA
mjenkins@cariari.ucr.ac.cr

Introduction
This short paper describes a pedagogical pattern to teach Object-Oriented Programming (OOP) to senior students based on a multi-language approach. The idea is to teach OOP concepts such as encapsulation, abstraction, and polymorphism, independently of the OOP language used. To do that, a in Design-Do-Redo-Redo (DDRR) pattern is used, in which students design an OOP solution to a programming assignment and then implement it in three different languages.

INTENT
Teach OOP concepts independently of any particular OOP language.

MOTIVATION
It has been long argued that OOP should be taught abstractly, that is, separately from the mechanisms and constructs some languages use to implement those programming concepts. However, Students often have a difficult time understanding OOP concepts such as encapsulation, abstraction and polymorphism independently of how particular languages implement them.

APPLICABILITY
Use the DDRR pattern to introduce several OOP concepts at the same time.

STRUCTURE
1. Students are assigned a small programming assignment specially designed to get them acquaintance with a small set of OOP concepts.
2. They first turn in the OO design using CRC cards.
3. The assignment is then implemented in one OOP language (e.g.,Smalltalk).
4. Students implement the same design in a sufficiently different OOP language (e.g., C++).
5. Students form groups of 2 or 3 and implement the same design but this time using a third OOP language. Each group is assigned a different language (e.g., Visual Basic, Delphi, Ada 95, SQLWindows, Flavors, Java, etc.).
6. Each group fills in a table showing how their assigend language implements the OOP concepts covered in class. The table with the criteria is provided by the instructor already filled with the features of the first two languages they used. Appendix 1 contains the criteria used in the table.
7. Finally, each group presents their results and analysis to the rest of the class.

CONSEQUENCES
1. Allows the students to get hands-on experience with three different OOP languages and environments.
2. They obtain a language-independent design of the problem using a simple design method.
3. They learn how to learn a new OOP language by their own.

IMPLEMENTATION
Issues to consider:
1. This pattern is designed for senior-level students who are already proficient in at least one programming language. Its use in introductory programming courses might be counterproductive.
2. The programming assignment must be carefully defined to assure that the students will be implementing the OOP concepts we want to teach them.
3. Giving the students a quick feedback on their work is critical. Assignments must be returned graded quickly so they can avoid making the same mistakes in subsequent assignments.

EXAMPLE INSTANCES OF THIS PATTERN
This pattern has been used to teach:
1. OOP concepts
2. OO design (CRC cards)
3. Smalltalk programming
4. C++ programming

EXPERIENCE
This pattern has been used twice during 1995 and 1996 with a total of 38 senior students. The results have been satisfactory, although further improvements can be done. We have to develop better and more comprehensive programming assignments and update our textbook.

Appendix 1: Criteria to evaluate an OOP

The evaluation table contains the following criteria:
- Encapsulation (of variables and methods)
- Polymorphism (genericity vrs. inheritance or both)
- Abstraction (degree of reusability)
- Inheritance (simple vrs. multiple, dynamic vrs. static)
- Types (typing system, if any)
- Binding of variables and methods (static vrs. dynamic or both)
- Memory management (manual or automatic)
- Syntax complexity
- Programming environment (windows, design toolkit, debugger, etc.)
- Interface to RDBMS (ODBC or otherwise)
- Language uniformity (hybrid vrs. pure OOP)

Pedagogical Pattern #14
Peer Review and Corrective Maintenance (PRCM) Pattern
(Version 1.0)
Fernando Brito e Abreu
INESC and Lisbon Technical University (ISEG)
Portugal
fba@tutankhamon.inesc.pt

INTENT
Expose students to:
- software quality techniques
- group dynamics situations
- software maintenance problems

MOTIVATION
Software developers often have to do maintenance (either corrective, adaptive or evolutive) on products or parts of products that they did not produce. This is enforced with OO technology because of the emphasis on reuse where you tend to adapt and extend existing components.
"Traditional" programming courses, however, often do not expose students to maintenance tasks. Systems produced by students are evaluated "as delivered" and as so graded. Even if they get back to students for correction, they will still work on their own products, not anybody else's.
On the other hand, students when faced with group assignments are tempted to cluster around the same colleagues over and over again, the ones with whom they feel better because they share common interests and views and with whom they do not conflict. Besides not mimicking the real world, this situation reduces the knowledge and insight sharing with members of other groups.
Last but not the least, verification and validation techniques used by students are often restricted to testing (mostly black- box). Software revisions in general, and software inspection techniques in particular, although recognized as very effective and efficient (due to their possible early adoption on the life-cycle) are seldom taught in OO software development courses. Enforcement of standardization rules and conventions is also often forgotten in academic assignments, although being of capital importance in industrial settings.

APPLICABILITY
This pattern can be used whenever there are team assignments to produce any software deliverable such as a requirements or design specification, source code, test battery, executable system, installation or user manuals.

STRUCTURE
Initial work:
Students are grouped in "n" teams (T1, T2, ..., Tn). Teams ranging from 2 to 4 elements are usually appropriate. All teams are given similar effort assignments but preferably distinct in scope. All assignments have well defined (as formally as possible) requirements and correspond to the production of a given software deliverable. These requirements will be used for deliverable validation. The rules and conventions for producing the required deliverable are also formally defined and will be used for deliverable verification.
After a stated period of time each team Ti must have produced a prototype Pi of the desired deliverable.

Peer Review:
The peer review session occurs for all groups at the same time in a special lab class during regular class hours. Each prototype Pi is reviewed by a team composed of one chosen (by the team mates) element of team Ti plus all minus one elements of team Ti+1 (or by T1 for Pn).
By other words, each team is like a node in a ring structure where all prototypes produced are shifted one position for review (and maintenance as we will see further on). One student representing the original producer is present in the review session, to contribute with his (her) special insight derived from having been involved in its conception.
The Fagan model of software inspections, or one of its variants, is a good choice for conducting the review session. In this formal approach to reviewing, a copy of the deliverable to be reviewed is distributed to each participant beforehand to allow an independent verification and validation process.
The meeting objective is identifying, classifying and registering defects, not proposing solutions for them. Each participant has a specific role (moderator, presenter, recorder, producer) which can be accumulated for review teams with less than 4 people. Moderator is compatible with any other role. If possible, producer should not accumulate with either presenter or recorder, not to bias the review results. The moderator is responsible for avoiding problem resolution (which extends the meeting duration) and conflicts. The presenter is responsible for the meeting pace. The recorder fills the review report. The producer role is conducted by the member representing the team which produced the prototype. The lecturer (or several teaching assistants) offers assistance wandering around teams and guaranteeing that interaction between them is kept to a minimum to minimize chaos. However, (s)he must keep a relatively low profile during this phase, allowing students to learn from each other, but helping to reconciliate possible contradicting conclusions.
This peer review meeting should take between one to two hours. Each team may complete the review activity at a different time. As they do so, they are invited to leave the lab, to avoid disturbing other reviews still taking place.
A copy of the review report is given to the lecturer.

Corrective Maintenance:
After doing a causal analysis based on all the review reports the lecturer gives a class summarizing the most common defects and their possible workarounds. Each team is assigned the task of corrective (defects found) and perfective (requirements not met) maintenance of the product they reviewed, not the one they produced. A given schedule for this rework effort is established.

CONSEQUENCES
This pattern:
- requires additional work on the part of the lecturer to prepare the detailed requirements checklists;
- forces students to record, and to reflect upon, what happened when they were involved in their work assignments;
- leads students to learn how to delegate and share responsibilities;
- exposes students to the problems and challenges of maintenance;
- allows the introduction of software quality principles and techniques and actual practice for students in exercising them;
- increases the learning potential by sharing other students' experiences and knowledge;
- allows students to give and receive critique to and from peers;
- avoids the frustration of egocentric students when they are required to redo their first solutions.

IMPLEMENTATION
Issues to consider:
- This pattern can be used repeatedly within the same course. An entire course can be organized as a sequence of instances of this pattern. These instances should not overlap in time.
- The material to be reviewed should not be tiny (see TSL pattern).
- The rating of a team is split in two parts, one due to the prototype they produced and other to the rework. A careful weight of each of the two parts is important. This avoids the reduction in the willingness of students to provide a wholehearted improved solution on both phases. Equal weights can be an appropriate approach.

The review report is composed of:
- a section for the identification of the deliverable being reviewed, preparation times, date, review duration, etc;
- a section for the identification of the review members (and their role if formal reviews are used);
- a section for registering and characterizing the defects found (type, location, description, possible cause);
- a verification and validation (V&V) checklist.

The V&V checklist contains:
- identification of each elementary or atomic requirement (specific to each assignment) - this allows the detection of missing forward traceability (stated requirements not implemented) or reverse traceability (implementation features not reflected in design).
- identification of each rule or convention to produce (common to all groups) - this allows the detection of non adherence to the adopted standards (naming conventions, documentation guidelines, indentation, use of headers, etc).

RELATED PATTERN
- EPIC pattern, since it also advocates peer work.
- DIRR pattern, since it also advocates a rework phase, although in a different framework.

EXAMPLE INSTANCES OF THIS PATTERN
This pattern has been used to teach OMT (Object Modeling Technique) and Object Pascal programming concepts (using Delphi). However, since it is defined in a general way, it can be used with any kind of software deliverable, either OO or not.

RESOURCES
The instantiation of this pattern requires the availability of a lab or classroom where several groups of students can work with as few interaction as possible from other groups under the supervision of one or more lecturers (that have to circulate among the groups). The preferred option is to have an independent table for each group around which its members can sit.

Pedagogical Pattern #15
Preparation, Industrial Presentation and Roundtable (PIPR) Pattern
(Version 1.0)
Fernando Brito e Abreu
INESC and Lisbon Technical University (ISEG)
Portugal
fba@tutankhamon.inesc.pt

INTENT
Bridging the gap between academia and the "real world".

MOTIVATION
It is often the case, mostly in countries where university staff spend their lifetime careers in academic campus, that software industry reality is quite different from the academic one. By the time students end their graduations and start working in industry, they feel completely unadjusted, either because their knowledge is not applicable or because they lack some basic understanding of what is day to day life in industry. This includes dealing with several constraints, human resources allocation, motivation, leadership, team dynamics, client pressure, marketing pressure, conflict resolution, technology migration problems, past experiences and selected tradeoffs and so on!
On the other hand, industry profits largely from having informal networks with university staff and students themselves because they can somehow indirectly shape the academic curricula to fit their real needs (by making the staff aware) and by establishing means of picking teaglesv among the students.

APPLICABILITY
This pattern can be used whenever the concepts being introduced in the classroom are being (or should be) used in production activities going on in the software industry.

STRUCTURE
Preparation:
It is the author's experience that much more insights are gained if students are taught what they are going to see or hear beforehand. This includes introducing, in the classroom, all the theoretical concepts related to the industrial presentation to be carried out at a later moment (eventually on another day). Students gain the ability to criticize and ask questions, that otherwise would only occur too late. Industrial presenter should also be tpreparedv (informal meeting with one academic lecturer) in the sense that (s)he must be aware of which is the basic background of the intended audience (the students) in order to shape its presentation.

Industrial Presentation:
The theme of the presentation can be varied: tools adoption, migrating legacy systems, dealing with human resources, calendar and budget constraints, enforcing reuse adoption, configuration management procedures, subcontracting policies, verification and validation mechanisms in use and so on. These presentations can be carried out in class (invited speaker approach). However, it would have much more impact if done at the industry premises (offices, labs, ...). Presentations should be carried out in normal working days when trealv activity is taking place. Weekend visits in empty premises are not a thrilling and enriching experience. If presentation involves a site tour, students should be split in small groups and taught to minimize the risk of being intrusive.

Roundtable:
After the presentation is over, all students, respective teachers and industrial presenter(s) gather in one room where they can ask and share with others whatever doubts, questions and comments they feel appropriate. The teacher may start with some preliminary questions, although (s)he may already know the answers, in order to stimulate the discussion session. This meeting should not take more than one hour.

CONSEQUENCES
The PIPR pattern:
- provides the students (and in fact the lecturers themselves) with a more realistic view of what are the problems faced by real world projects in the software industry;
- enables lecturers to give more concrete, less abstract, lectures;
- allows students to realize "why" rather than on "how" things are done;
- invites students to reflect on what they have learned;
- makes the learning process more fun by introducing external agents and probably external visits (multinationals have long understood the benefit of conducting kickoffs).

IMPLEMENTATION
Issues to consider:
- this pattern can be instantiated several times in the same term;
- distant visits should be avoided because some students may not afford the costs involved and because it can take too much time.

RELATED PATTERN
(none so far)

EXAMPLE INSTANCES OF THIS PATTERN
This pattern has been used to teach Software Engineering Project Management and Software Quality Principles and Techniques. Its generality is believed to allow it to be equally applied in other teaching areas.

RESOURCES
The instantiation of this method requires that the lecturer have contacts in industry or that (s)he is allowed the opportunity and budget to visit a few industries in order to select, negotiate and plan the interaction events.

Pedagogical Pattern #16
Physical Analogy Pattern
(Version 1.0)

Phil McLaughlin
ParcPlace-Digitalk UK
Waverly House, Farnham Business Park
Farnham
Surrey GU9 8QT
United Kingdom
p.mclaughlin@soc.staffs.ac.uk

INTENT
Use some real world objects to role play object concepts in order to reinforce object thinking.

MOTIVATION
Students new to Object Technology are frequently told about modeling objects in the 'real world'. Physical analogy helps to demonstrate key concepts and presents another metaphor to students as a mental cross reference for the topic. This is not a new concept.

APPLICABILITY
Use Physical Analogy to reinforce concepts delivered in more traditional means

STRUCTURE
Take whatever concept is being taught and use inanimate objects and/or the students in order to demonstrate it. There is some risk involved and careful judgement of the group dynamic is required from the tutor.

CONSEQUENCES
Traditional teaching (verbal / visual) of concepts is backed up by physical movement memory (kinesthetic - if memory serves correctly) thus enhancing retention.

IMPLEMENTATION
Issues to Consider

1) Group Dynamic is important, Using Physical Analogy with some students may cause offence due to culture or other reasons.

2) The example must be appropriate and simple or more time is spent explaining the scenario than the concept

3) Short demonstrations have more impact

EXAMPLE INSTANCE

Concept:
Message Passing and Encapsulation

Intent:
Introduce message passing and encapsulation and provide a demonstration of how the OO approach is inherently more robust than the procedural.

Method:
Pick two students.
Pick the most outgoing and try to lift him/her out of their seat without telling them what you are doing.
On a piece of paper write "Please stand up" and hand this to the other student.
Get them seated again and explain the demonstration

If It Works:
1) Students should appreciate that when sent an appropriate message behaviour is induced robustly.
2) Students should also appreciate that external functions acting on a data structure (trying to rearrange the state of the students musculo-skeletal system) is prone to error unless the exact algorithm is applied to identical objects.
3) If the piece of paper is passed around the room, the state of the entire collection of objects is changed purely due to message passing with encapsulated behaviour. One person may stand up differently to the next and so on.. but the desired result is achieved without undue problem.

Issues to consider:
Be careful in choice of analogy and 'victim' in order to avoid causing offence (to physically challenged students for example).
Try not to pick the largest and heaviest student in the room to manipulate. Whilst highly amusing to the students and still possible to explain why the algorithm doesn't work, you run the risk of missing the point (and hurting yourself !)

Alternative:
If manipulating students is unacceptable try having them write name badges. Pass a message to one student to write their name on the board showing encapsulated behaviour. Take the name badge of another student, copy the name onto the board and throw the badge into the nearest bin (return value not specified by algorithm). This works almost as well.

Pedagogical Pattern #17
The Three Bears Pattern
(Version 1.0)

Kent Beck
First Class Software, Inc.
P.O. Box 226
Boulder Creek, CA 95006 USA
70761.1216@compuserve.com

INTENT
Remove "fear of failure" as a barrier to learning by making failure part of the goal.

MOTIVATION
Learning is experiential. Without experience, there is no learning. However much the learner wants to learn, getting over the barriers to experience can impede or even completely block learning.
Confident learners to use failure and frustration as investments whose payoff comes in future success. Most traditional schooling systems are so effective at punishing failure that the confidence to fail is rare and dearly bought (and who said the school system can't teach?)

Many topics challenge the learner to find a balance along some continuum. How much should a point guard shoot? How often should a developer refactor? How strictly should a musician follow the rhythm? Effectively answering these questions requires that the learner discover a position or range along a continuum from "too much" to "not enough".

Learning to find a balance poses particularly severe barriers to gaining experience for the learner. There is no chance the learner will be successful the first time, unlike many other learning activities. Even if they fell into the right balance, chances are the learner would not recognize that the balance would be struck.

STRUCTURE

Continuum- Define the continuum for the learner. A simple approach is to explain the reductio ad absurdum on either end.

Experiment- Give the learner a chance to locate the balance in three places- either end of the continuum and right in the middle.

Review- Give the learner the chance to reflect on the three experiments.

IMPLEMENTATION

1. Define the continuum- I have had good luck with the reductio ad absurdum strategy. I also like posing a set of questions that will be asked of the resulting balance. For example, in reviewing the point guard's decision about how much to shoot, I would ask "Did the other players get into the flow of the game?" "Was the defense forced to guard you closely?" "Did you win?"

2. Conduct the experiment- You want the learner to experience all three options close enough in time to accurately compare them. Reduce the topic to something that can be accomplished in less than an hour, if possible.

3. Review the experiment- One technique I've found helpful is to have the learner briefly present the three solutions, then have the rest of the class guess which was which. This can help learners who haven't yet learned the true boundaries of the continuum.

CONSEQUENCES
+The learner has failure as a goal, so fear of failure will be less of a problem. Some learners just can't get over the fact that they "have to do it right" eventually, however.
+The learner understands the continuum by explicitly experiencing its ends. -You may have over-simplified the topic for the learner by reducing the topic to a single continuum.

KNOWN USES
I may have picked this technique up from "Disney Animation: The Illusion of Life" by Frank Thomas and Ollie Johnston. In it, they relate the story of a frustrated Walt Disney telling his animators to exaggerate the movement of characters. The result was just what he was looking for.

I have taught requirements engineering with this technique. I ask the learners to write stories that will define the system- one too large in scope to be useful, one too small, and one just right. I taught this technique in India and ended up telling the story of Goldilocks and the Three Bears after lunch.

I have taught pattern writing with the Three Bears. Tyro pattern writers often struggle to find the appropriate scope for their patterns.

I use The Three Bears in my own learning all the time. When I got a Smalltalk with the constraint-ish ValueModel framework, I deliberately wrote a system that used it too much. When I learn a piece of music, I deliberately play it like a metronome and with the beat wandering all over.

Pedagogical Pattern #18
Discussion-Activity-Review-Lab-Review Pattern
(Version 1.0)
Gary L. Craig
Superlative Software Solutions, Inc.
5800 Magellan Way #107
Raleigh, NC 27612 USA
craig@cat.syr.edu
http://www.cat.syr.edu/3Si

INTENT
Present ideas which must be considered at a variety of abstraction levels

MOTIVATION
There are many OO concepts which must be understood at several abstraction level s, e.g., Polymorphism -- which has implication on design and programming. In gener al aniterative approach to learning is best; but not always the most effective from a time management perspective. This pattern in some ways is an extension to the discus sion-lab paradigm. The goal is to permit the student to embrace an abstract view before tackling a more concrete view.

APPLICABILITY
Use the DARLR pattern to link two abstraction levels for a topic. Introduce th e high level material in context through a guided activity; followed by "implementation " as an exercise.

STRUCTURE

Discussion:
Establish the context for the development cycle. Utilize the property of large group discussion to stimulate the class.

Activity:
Once the big picture has been established through the class-wide discussion, move forward to small group exercises. This permits more specific (detailed) issues to be considered.

Review:
Bring the class back together to evaluate the different results (e.g., analysis models, design models, ...). Consider the alternatives observed. Determine a "common" set of "work-products". Transition to the next abstraction layer, i.e., raise the issues.

Lab:
For most analysis/design and design/implementation steps, the "lower" abstraction layer can be produced in part through a transformation. This transformation should be performed as an exercise.

Review: Evaluate results of Lab work. In addition, the mapping between abstraction levels is reviewed.

CONSEQUENCES

There is linking between development phases. Both models and mapping between them can be reviewed for consistency. For example, development of an analysis model; followed by discussion of impact on design; followed by design exercise; followed by a review of the resultant design model including reflection back to the analysis model.

This pattern can be exploited and tuned to highlight either "phase". For example, one may have a design discussion to clarify the requirements for the implementation task. The design may only be roughed out (or certain non-functional requirement left unconsidered). Alternatively, the design discussion may be very involved, and the coding is performed (perhaps only at pseudo-code level) to validate the "workability" of the design.

IMPLEMENTATION
Issues to consider:
1) What is to be emphasized, e.g., phase 1, phase 2, or the transformation process between the phases. This drives the level of detailed required in each discussion/activity/lab/reviews.

2) What measure is to be used to evaluate consistency between abstraction levels. Such measures may be "access paths"; scenarios; metrics; ...

RELATED PATTERN
(none as yet)

EXAMPLE INSTANCES OF PATTERN
Used frequently in analysis and design courses to show the relationship between these phases; and provide context for decisions made.

Very successful for "involved" coding exercises where design issues can be contained within a separate design discussion. At the completion of the design exercise, student have a sense of "ownership" of the problem and subsequent design -- and can concentrate on the implementation issues. (This has been employed in teaching "synchronization" mechanisms in Java. The overall concurrent architecture is designed in a separate discussion prior to doing the implementation lab.)

Pedagogical Pattern #19
Gagne'-Ausbel Pattern of Lecture (GAP) Pattern
(Version 1.0)
Tim DeClue
Dept. of Computer and Information Sciences
Southwest Baptist University
Bolivar, MO 65613 USA
tdeclue@sbuniv.edu

INTENT
To make use of learning theory concepts to improve the effectiveness of lecture sessions.

MOTIVATION
Traditional lecture is often less effective for many students because it allows them to be passive in the learning process. Unfortunately, this type of learning environments still permeates most college and university computer science curricula. There are, however, some steps that can be taken to make the students active learners, and therefore be more effective from the standpoint of learning. These steps may mean more planning and work by the instructor, but in the long run it is the student who benefits. This pattern makes use of a theory of learning which in large part can be traced to the writings of Robert Gagne' and David Ausubel. For this reason the pattern may be referred to as the Gagne-Ausubel Pattern of Lecture (GAP).

APPLICABILITY
The GAP was designed improve lessons previously taught using a traditional lecture format. The GAP may be used in most lecture situations, but it is particularly effective when using presentation software such as Microsoft Powerpoint or Aldus Persuasion, or when teaching a procedure, as in the formulation and object-oriented analysis of a problem statement, or in the translation of a well-written header file into its implemented counterpart.

STRUCTURE

Introduction:
Begin the lecture by gaining the attention of your students with a focusing event. The focusing event should center the students' attention, and usually introduces a question which can only be answered by mastering the content of the lecture. Sometimes it is helpful to use visual aids, but many times at the college level an intriguing question followed by a couple of minutes of discussion can suffice.

After gaining the attention of your students, remind them of any prior learning (prerequisites) that they have already been exposed to which deals with the content to be presented. Let the students know, in some detail, what the object of the lecture is, and inform them how they will be tested over the content. In other words, justify the effort it is going to take to learn the material.

This introduction should serve as the Ausubelian "advance organizer" which activates prior learning for the purpose of acquiring new knowledge. As advocated by Gagne' , the objective should be presented in behavioral terms, but in the language and format understood by the students. These two components, the advance organizer and objective, help produce a mind set in your students which readies them for new learning

Presentation of New Content:
The new content may be presented in terms of traditional lecture, but with two very important differences. First, lecture sessions should be limited to around 10-15 minutes, and second, questioning should be used to gauge the amount of learning which is taking place. Questions should be asked of the entire class, and should be worded in such a way as to discourage yes/no answers. Further, the entire class should be given a few seconds to think about the question before an answer is required of a specific student.

Any concepts which are introduced should be illustrated with clear examples. If the content is too complex to be presented in around 10 minutes, then the content should probably be broken up into smaller chunks which can more easily be assimilated by the students.

Practice:
Once the new content has been introduced, the students should be given a chance to practice doing whatever it is that has been introduced. It is not necessary that students work in small groups of 3 or 4 when practicing, but working in groups does have some important and positive implications discussed in the consequences section of this document If groups are used, it is recommended that specific roles be assigned to each student in the group so that no individual may remain passive during this portion of the lesson

Feedback and Correctives:
While students are working in groups, the instructor should monitor the work, occasionally asking groups to justify their decisions. Often it is quite useful to have groups put the result of their work on a markerboard or piece of paper. Other groups then have the chance to provide feedback on the quality of the work, and further sparks class-wide discussions. To conclude this portion of the lesson, the instructor may wish to display the model case example with the class, and point out differences between the efforts of the student groups and the model case.

Independent Practice:
Some component of the lesson should be assigned for outside work. According to Gagne', revisiting the lesson content outside of class strengthens the recall at a later time, and provides an opportunity for generalization of the learning (applying the lesson to new, never before encountered problems). This step is usually not too difficult; most textbooks have questions at the end of the chapter, and often the model case presented in class can be used as a springboard for a slightly more complicated assignment, or even a full program. Furthermore, most CS1 and CS2 courses have a lab component which can be used for this purpose.

CONSEQUENCES
The GAP pattern:
- allows students to become active learners, as opposed to being passive learners in traditional lecture.
- allows students to have a chance to learn from and teach their peers. Peer to peer instruction is a powerful tool acknowledged by most learning theorists due to the important role that modeling plays in learning.
- uses group work (collaborative learning), which lessens the emphasis on competitive assessment, often cited as one of the reasons females experience higher attrition rates in computer science. Group work gives students who are more hesitant to participate in classroom discussion a chance to ask and discuss questions in a less threatening environment.
- may increase planning time because group work is not as easily "scripted" as is pure lecture.
- incorporates a method for generalizing learning through work outside of class.
- gives the instructor an opportunity to provide feedback to specific groups and individual students in the lecture setting.

IMPLEMENTATION
Issues to consider:
- Labwork is considered one of the best methods for reinforcing the content presented in lecture. Because students have worked in groups in class, it is a natural extension to continue to use groups in the lab. This teamwork in the lab mimics real-life situations where programmers are frequently a part of a team.
- Object orientation is first encountered as an analysis tool for a problem domain. This analysis technique is a kind of procedure, the very type of learning best taught using GAP.
- Object orientation uses the concept of classes, which have attributes setting one class apart from other classes, as well as the concepts of inheritance, inclusion, etc. According to learning theory, concepts are best taught using example techniques. Model cases, anti-cases, variance of clarity, and increasing detail are all techniques used in teaching concepts, and are encouraged in the GAP.

EXAMPLE INSTANCES
This pattern has been used to teach CS1 and CS2 using C++ and object orientation as the basis for learning.

Pedagogical Pattern #20
Identity Pattern
(Version 1.0)
Maximo Prieto and Pablo Victory
LIFIA. Departamento de Informatica. Facultad de Ciencias Exactas.
Universidad Nacional de La Plata.
also Depto. de Computacin. Fac. de Ccs. Exactas y Naturales.
Universidad Nacional de Buenos Aires.
Argentina
E-mail: [maximo, victory]@info.unlp.edu.ar

INTENT
The intent of this pattern is to teach the concept of object identity and detect whether the students are having trouble grasping this concept.

MOTIVATION
Students have trouble grasping the identity concept in object oriented programming. This is especially true if the students have a structured programming background. Usually students want to put an identification code to each and every object they identify. This is usually the first step after they identify a class.
The vast majority of programming languages and database languages use variable names to distinguish temporary values or "objects". The are effectively mixing the concepts of addressability and identity. Most database management systems use identifier keys to identify rows, tuples or "persistent objects". The are mixing data value and identity. This distinction between the name of an object and the object itself or its identity is the kind of problem the Identity pattern wishes to address.
Students with previous knowledge of traditional design technics have difficulty grasping the identity concept. Most probably, every tool and language they have used required that they define the key or index of the record, register or table they used. They tend to carry this practice into object oriented programming. They can not understand how any entity can still be the same entity even when its "code" has changed. Moreover, they have problems understanding how two different objects, let',s say object A and object B, can reference a third object (object C) by a different name each. They can not conceive how; if object C is changed by object A, the change can be seen by obje ct B too.

APPLICABILITY
Use the Identity Problem pattern when:
- Students tend to put a "code" or identifier field to every object they create and manipulate.
- Students end up implementing messages, in domain model objects, like:

#rentCar: aPlateNumber toClient: aName

Note that both objects, the car and the client who wants to rent it, are represented by their corresponding "identifier code".
You want to teach the identity concept to new students with no prior background in computer science.

STRUCTURE
They should model problems in which the identity of the objects is the key to solve them. These exercises should present them with objects whose identity can not be determine in the traditional way. For example:
Implement a chess (or checkers) game for two human players. Model the board and the pieces. The user should be able to select any piece from the board and obtain a report of the next five moves that piece will perform during the course of a normal chess game.
The problem is correctly solved if:
Each piece is a single different object.
Each cell in the board is a single different object.
No identity code is used to identify each of the different pawns, rooks, bishops or knights of any color.

CONSEQUENCES
The Identity pattern should help students understand that: - Identity is that property of an object which distinguishes it from all other objects, regardless its internal state.
- The identity of an object is preserved even when the state of that object is completely changed.

Pedagogical Pattern #21
Mission Impossible Pattern
(See above in group of patterns in newly revised format)

Pedagogical Pattern #22
Simulation Game Workshop Pattern
(Version 1.0)
Alan O'Callaghan
Chair, Object Technology Group
De Montfort University
School of Computing Sciences
The Gateway
LEICESTER LE1 9BH
aoc@dmu.ac.uk

MOTIVATION
Provides a simulated learning environment in the form of a game which nevertheless involves some important "real world" concepts. The pattern also provides, for large groups of learners, the possibility of using exercises that give them a feel for what is abstractly general and what is variable in a particular scenario.

FORCES
* OT is, in software engineering practice, arguably concerned about "programming-in-the-large" and about the structure of software systems. It is difficult, if not impossible, to reproduce such systems (and therefore the problems they exhibit) in the classroom.
* A problem with most scenario workshops is that they are too specific, and have an artificial "feel" about them. The necessary suspension of belief on behalf of the learner that is necessary to engage with the problem sometimes has the effect of further distancing the learner from the learning in the exercise.
* Games use the "suspension of belief" to create a virtual world with which the learner is able to engage sometimes because of (rather than in spite of) their artificiality.

APPLICABILITY
Works best in large groups, allowing six to eight teams to be formed, each composed of 6-8 persons.
Requires a sizeable time-slot, min. 3 hours.

CONSEQUENCES
Learners are able to develop their own solutions to an artificial problem, and then compare them with other groups. This can provoke discussion as to why there are differences. Care has to be taken to reduce, or better still, eliminate the "mine is the best solution" syndrome which diverts learners from constructive self-criticism.

IMPLEMENTATION
A short scenario, the main elements of which can be described in 10-15 minutes is presented. Each group is also presented with additional information on an A4 sheet containing no more than 4 paragraphs, each paragraph dealing with a discrete factor. For each group one paragraph of the information differs from that in the master template - so that while every group will have 3 paragraphs out of 4 in common with most groups, its own information is unique. However, at this stage, each group will believe itself to have exactly the same information as every other.

Additional information, simulating dynamic changes in requirements, are "drip-fed" into the groups' discussion of the set problem at 20-30 min. intervals. Each one of these changes has impact relating to the information contained in the A4 sheet.

Some common form of representation of solutions is required from each team, preferably a display poster. Prior to summation by the educator(s), each team will nominate one person to explain their solution to people from other groups. This person will stay with the poster. All other team members are invited to visit all other posters, ask questions about the decisions taken, and then report back for comparison and discussion. At this point it will dawn on participants that each team had a slightly different scenario. The educator will sum up, highlighting the points of commonality between the problems, and how they varied, and any commonalities between the solutions offered.

EXAMPLE OF USE
This pattern was used in the development of the workshop on OT Migration and Legacy Systems at the Object Technology '96 conference, Oxford, UK by the Object Engineering and Migration group from De Montfort University.

RELATED PATTERN
None.

Pedagogical Pattern #23
Model and Implement Pattern
(Version 1.0)
Alan O'Callaghan
Chair, Object Technology Group
De Montfort University
School of Computing Sciences
The Gateway
LEICESTER LE1 9BH
aoc@dmu.ac.uk

MOTIVATION
Traditional Computer Science teaching requires a decidedly bottom-up approach demanding that students learn numbering systems, the principles of digital design, a procedural programming language and then, scaling up, some analysis and design. The approach to programming is syntax-driven rather than, as all "real world" computing demands, problem-driven. An alternative approach which stresses programming as a means to solving problems is required.

FORCES
* First year students' grasp of abstraction is insufficient for a "pure modelling" course.
* Learners respond to hands-on exercises and the achievement of creating software that works
* Traditional curricula reinforce a bottom-up approach in which analysis and design are regarded as "high level" techniques to be encountered much later in the course. The effect is to impose a machine-view architecture on problem-solving approaches.
* An appreciation of OT requires early and often exposure to conceptual modelling, software design, and implementation.

APPLICABILITY
Applies to all levels in Higher Education computing curricula where "real-world" problems(ie. Non-computing) problems have to be solved using software. It is less important for students studying hardware, digital design or electronic engineering.
Applies also to learners being reskilled in industry.
Requires a suitable interactive, graphical programming environment e.g., SmallTalk rather than C++, for best results, or alternatively, a robust, mature and wide-ranging library of classes which learners can use as components in creating a solution to a problem.
Definitely does not require competence in a specific analysis/design method or notation

CONSEQUENCES
Early understanding of a programming environment (e.g., language compiler) as a tool providing a means to an end, rather than as a means in itself.
Greater understanding of software as a tool for solving "real world" problems rather than as an instruction set for the machine.
Early exposure to the modelling power of objects.
Firmer ground established for "scaling up" to analysis, design and implementation of large-scale systems later on in a course.

IMPLEMENTATION
Requires a suitable programming environment (see above)
Requires a prepared set of logical problems, and a defined set of software components that can be put together (after some analysis) to provide an executable solution.
Implies a restructuring of the wider curriculum, perhaps in the form of Meyer's inverted curriculum [Meyer 1994], to take care of important notions in Computer Science which are traditionally taught early on.

EXAMPLE OF USE
De Montfort University in the UK have applied this pattern in programming subjects since 1993, when it was applied to a Modula-2 course. Its success led to the embracement of OT in early programming modules such that from 1996-7 Java is taught as a first programming language in some courses. From 1997-8, SmallTalk - currently taught in the application of this pattern from the Second Year - will also be available at Level One.

RELATED PATTERN
Can be regarded as a special variant of PDR [Lilly 1996]

References
[Gamma 1994] Gamma E., et al. 1994. Design Patterns for Reuse. Addison-Wesley, Reading, MA.
[Lilly 1996] Lilly, s. 1996. "Patterns for Pedagogy" in Object Magazine 1/96.
[Meyer 1994] Meyer, B (Reference to be supplied)

Pedagogical Pattern #24
Client-Server-Negotiation (CSN) Pattern
(Version 1.0)
Eliezer Kantorowitz
CS Dept. Technion Haifa
Kantor@csa.Technion.ac.il
Fanny-Michaela Reisin
CS Dept. Technical College Berlin
reisin@cs.tu-berlin.de

INTENT
To enable students to experience practically such advantages of oo technology like for instance conceptual adequacy, seamlessness, requirement traceability, or component reusability by taking over client/server responsibilities.

MOTIVATION
We relate the benefits mentioned above to two principles of oo abstraction, which we call service encapsulation and service implementation hiding. In this view each object(-class) is considered to be a service supplier, i.e. a server. Most of the objects are also service applier, i.e. clients. Objects, which are clients only and don't "serve" at all, are excluded from this view. Any modeled server object is assumed to have at least one client, who "uses" its services and hence to be one part of a client-server-association.
In this view the service interface of every modeled object be specified in terms of a client-server-contract, i.e. of an agreement of mutual requirements and assurances between the server object and each of its client objects (Meyer 88). Such a contract comprises the use-related abstraction of the services, which are encapsulated and implemented by the very server object as well as the conditions, which must be met, in order to guarantee the validity, consistency, and integrity of:
- the object, that encapsulates specific services as a whole
- any single service
- the given system, composed of interrelated objects or object (sub-)systems.

The conditions, which have to be assured by a client (and are thus required by the server) before the server "runs a called service" are fixed in the contract as service- related preconditions. The conditions, which have to be assured by the server (and are thus required by the client) "after having run a called service", are fixed in the contract as service-related postconditions or/and as object-related behavior invariants.
Starting out from here, we extend Bertrand Meyer's well known "design-by- contract"-metaphor to an overall modeling-by-contract-metaphor (Meyer 88). Our integrated course "Object Oriented System Development" (15 weeks), which is composed of a lecture (1.5 h per week) and a semester exercise (1.5 h tutorial per week) is triggered by the Client-Server-Negotiation-Concept, which is in fact a pedagogical pattern (Lilly 1996) for all negotiation activities between the students who represent either human software customers/users and suppliers or else the developers of client rsp. server objects. Owing to the conceptual seamlessness of oo modeling the client-server negotiations on object contracts repeat in the different stages of the software development process whereas the pattern's "instantiations" i.e. the actually negotiating clients resp. servers and especially the subjects of their negotiations vary all the time. Thus the CSN-Pattern turns out appropriate to teach both, the different functional roles in oosd and the different aspects of the evolving objects(-system) from the very first stage of the user requirement desription throughout the stages of requirement analysis, design, and program modeling.

APPLICATION
Apply the CSN-Pattern to teach and exemplify specific benefits of the object modeling process (client-server-negotiations) as well as specific properties of the resulting objects (server-interface resp. client-server-contract- specifications).
It was already mentioned above, that the CSN-Pattern is applicable to all oo modeling tasks and stages because of the conceptual seamlessness of the object development process. Since the concepts to specify constraints in terms of object and service related pre- and postconditions, which were originally introduced by Bertrand Meyer (Meyer 88) for the programming language Eiffel, are adapted by now for any stage of oo modeling (Coleman et al. 94, Rumbaugh et al. 91, Rumbaugh 95) the CSN-Pattern is particularly appropriate to focus on these benefits of object modeling throughout the sd process.

STRUCTURE
During the various stages of the system development process the students, who work in teams of, say 2-3 members, change functional roles according to the predefined oo modeling tasks and client/server "instantiations" for each stage of the predefined oosd process. The negotiation activities comprise mutual communication and learning processes with the aim to reach a consensus and to specify an object- resp. service-related contract. The CSN pattern structure does not change. The following "instantiations" for selected tasks in different stages of the oosd process may illustrate the pattern's structure:

User Requirement Description
Client - Customer (resp. User)
Server - Software manufacturer (resp. software developer)
Negotiations - Computer supported system envisioned by the client and by the server
Contract - Use cases - and/or other requirement descriptions.

Requirement Analysis - Object modeling
Client - User
Server - Software developer
Negotiation - The object system required by the client, i. e. the object model, to which further models will refer
Contract - Requirement object model specification.

Requirement Analysis - Function modeling (Fusion, UML)
Client - Human user / client object developer
Server - Software developer
Negotiation - The functionality and constraints of any single service
Contract - Service specification (UML: “operation specification
”, Fusion: “operation schemes”UML), commprisinthe signature as well as the elicitated constraints (pre- and postcondition) of each required service.

Design modeling - Object modeling
Client - Client object designer (software developer)
Server - Server object designer (software developer)
Negotiation - Structural and functional integrity of the designed object system, in order to assure the required behavior
Contract - Design Specification (objects and object (sub-)systems.

The oo contract negoticoations and specification activities during later stages as f. e. the programming, evaluation, validation stage may be designed accordingly. It should be pointed out that the environments of programming language like Eiffel 3.0, Ada 95 and C++ support the evaluation and check of object interfaces, which are specified in terms of contracts resp. service and behavior related constraints.

CONSEQUENCES
The CSN-Pattern
- supports learning by doing and gives students responsibilities for process and product related tasks during sd
- enables students to experience the different perspectives and roles throughout the process of oosd
- enables instructors to concentrate on specific features, benefits, and pitfalls of oosd
- enable the students to experience the negotiations of service interfaces contracts for oo subsystems of a larger project.
Since the student (-groups) are involved in true responsibilities and obligations their motivation and engagement are intrinsic.

IMPLEMENTATION
The CSN-Pattern requires
- exercises and sub-exercises, that include non trivial negotiation and management tasks
- more management on the side of students and lecturers, i. e. more time for the exercise conduction
- oo methods and tools (UML, Fusion, Objectory) and oo programming environments like Eiffel, Ada 95, C++ (incl. exception handler).

RELATED PATTERN
None.

EXAMPLE INSTANCES
The CSN-Pattern has been used to teach and train oosd using:
- OMT and Eiffel as PL + environment (Berlin)
- OMT and Ada 95 as PL + environment (Berlin)
- Fusion and C++ as PL + exception handling (Berlin).

Pedagogical Pattern #25
BASE-and-Supplementary-Languages in Lectures (BSLL) Pattern
(Version 1.0)
Raimundas Vaitkevitchius
Vytautas Magnus University at Kaunas
Informatics faculty
Vileikos 8, Kaunas 3000, Lithuania
(8-370) 796792
iirava@vdu.lt
rvaitk@soften.ktu.lt

INTENT
Avoiding students indentifying OOP with one programming language. Supplementing the course with essential OO-features not provided by the base language

MOTIVATION
1. Students often identify OOP with the programming language which is used in an introductory course. This can make their OO-thinking not so broad and flexible. They can be less ready to meat challenges of learning and using other languages when they start to work.
2. Usually one OO-language (even a pure one) doesn't support all the essential OO-concepts and principles. For instance, Smalltalk is considered to be "very" object-oriented and suitable for an introductory OOP course. However, it doesn't support multiple inheritence (MI). It is a matter of discussion, "how much" MI is needed in OOP languages and if it is needed at all. Nevertheless, students should know at least what MI is. Another example is an important question of types in OOP languages and differences between typed and untyped languages, early and late binding. Smalltalk doesn't have types, therefore it cannot provide relevant examples.

Using at least two OOP languages gives much broader view of OOP and provides much more possibilities for the course. One language is the base language. It is used for labs and (presumably) for students' applications. The second language is supplementary and it is used for some lecture examples and (sometimes) for students' applications.

A good example pair is Smalltalk and C++ (or vice versa). Some would think that it is possible to teach the base concepts of object orientation without programming languages at all. In essence, this is true. However, expressing OO-concepts in programming languages (and possibly developing interesting applications) gives students much more confidence in OO-approach, makes course more practical and interesting. CS students, especially in their last two undergraduate years, are more used to express their thinking in computer programms than in other models (although these other models can be used just as well).

APPLICABILITY

The BASE-and-Supplementary-Languages in Lectures pattern can usually be applied only for students who already have some experience in a supplementary language (or a similar language). The pattern is intended more for advanced students - 3-rd year or later.

Use the BSLL pattern to explain and illustrate the concepts of OOP which are not supported by the base language. Use the BSLL pattern to give your students a general view of OOP, to discuss differences between languages, their advantages and shortcomings, to have more tools for students to develop their applications.

STRUCTURE

Lecture examples are given using mainly the base language. The supplementary language is used, when:
- the base language doesn't support the concept being explained (or the support is not adequate)
- differences between implementations of the concept in different languages are discussed.

It is recommended to give a concise introduction to the supplementary language at the beginning. The goal of this introduction is to remindstudents the syntax and the basic constructs of the language. However, this is possible only when having enough time for lectures.

CONSEQUENCES
The BSLL pattern:
- allows students to form a broader and more general view of OO-approach
- improves understanding of essential OOP features
- encourages students to compare languages and to think about them critically
- accustoms students to the thought that they probably would use many languages in their future
- makes lectures more interesting and practical
- raises authority of the teacher (he or she knows many languages!)
- as a side effect, improves knowledge of the supplementary language
- requires the sufficient knowledge of the supplementary language by the teacher
- can require a bit more time (but not necessarily) in preparing lectures
- can be relatively difficult to those students who don't like programming (if there are such)

IMPLEMENTATION
Issues to consider:
- Choice of the supplementary language (after the base language is already chosen). It should be complementary to the base language. E.g., if the base language is pure, the supplementary one should by hybrid. If the base language is untyped, the supplementary one should be typed. If the base language doesn't support MI, the supplementary one should suppoert, etc . The choice is relatively easy (if there are no other restrictions) because there are many OOP (including hybrid ones) languages now. Of course, the teacher should know the supplementary language himself.
- It is not recommended to give students too complicated examples in a supplementary language which would use intricate or less known constructs of the language.

RELATED PATTERNS
(none so far)

EXAMPLE INSTANCES OF THIS PATTERN
- This pattern has been used in several introductory OOP courses at Vytautas Magnus University and Kaunas University of Technology, Lithuania. Students were mostly 3-rd year Informatics faculty students. All of them had previous procedural programming (mostly in Pascal, some in C) experience. The base language was Smalltalk, the supplementary languages were C++ and sometimes Turbo Pascal. Our experience shows that simple examples in C++, explaining such concepts, like export control, virtual functions, MI are easily understood by all the students who have learned at least Pascal.

Pedagogical Pattern #26
Educational Paradigm Factory Pattern
(Version 1.0)
Michael Whitelaw
Charles Sturt University - Riverina
Locked Bag 675
Wagga Wagga 2678 Australia
mwhitelaw@csu.edu.au

INTENT
Allows the specification of teaching methods without specifying the concrete teaching pattern

MOTIVATION
A particular teaching methodology can be used across a range of actual presentation patterns. To be portable across this range it is necessary to specify the essential ingedients for the particular teaching methodology and allow implementation to be performed by an abstract factory class that has an abstract method for each activity required by the paradigm. Concrete subclasses will return the actual method of implementation.

One common situation where this flexibility is required is where the timetable prevents all students in a class from having a similar instruction pattern. By using a factory pattern the educational paradigm can be mapped to the available instructional patterns implied by the timetable.

Another use is in the first semester of programming. Here the concrete teaching pattern can be considered to be fixed by the timetabler well in advance. However the educator wishes to vary the teaching methods during the semester. Early in the semester the educator may wish to use an aural-oral teaching paradigm to support students developing the basic paradigm, or idiom. Later in the semester, the educator switches to a more laissez-faire approach allowing students more latitude in constructing meaning of Object-oriented technology.

APPLICABILITY
The educational paradigm factory pattern is used when
- the educational principles should be independent of the actual teaching pattern
- the teaching process can be undertaken with a range of concrete patterns
- a number of teaching sessions need to have enforced consistent educational principles
- you want to be able to discuss the educational principles involved without actually dealling with their implementation

STRUCTURE
There is a set of educational goals (the abstract factory) which are made operational by concrete interpretations according to a specific learning theory (each one forms a concrete factory). The abstract factory uses abstract educational settings for the specification of the parts of the goal. The concrete factory uses concrete classes of the abstract settings to provide the implementation of the goal.

CONSEQUENCES
Separating out the abstract pattern allows better control of the types of educational experience that a student has. By specifying the experience that the student has to have independently of any particular teaching pattern, it is possible to change the concrete teaching pattern without changing the overall objectives.

By specifying the educational goals separately to the implementation it is possible to have all parts of the students educational experience based on one set of educational goals.

However because the educational goals are specified for all concrete implementations, it is difficult to change the learning theory easily.

IMPLEMENTATION
The most difficult part in implementation of an educational paradigm factory method is getting agreement among the multiple staff involved. Often there is a need to train tutors and similar staff in a particular set of educational goals. This can be time consuming.

Educational theories are usually not as precisely expressed as is desirable. Team teaching is one method of getting practical agreement among staff as to the implementation of a particular teaching paradigm.

SAMPLE
Consider the application of the aural-oral principles of teaching to the concrete pattern of lecture- workshop-laboratory.

The aural-oral teaching method is used by foreign language teachers to assist students to learn the idiom of a foreign language rather than the syntax or low level semantics. Apparently we are able to internalise the usage structure of a language least easily when reading, better when writing, better still when listening and best of all when speaking meaningful portions of the language. To make use of this order, students need to be immersed in a situation where they listen and talk the target language strictly using the desired idiom.

Foreign language teachers achieve this by requiring students to role play in a known common situation e.g. booking a hotel room. Each individual can then know the goal of the situation so can strive to make a contribution that is a sensible complete logical statement. More emphasis is made on achieving a contribution that has global meaning in the situation and less emphasis is placed on syntactic detail. Once the conversation is developed the students can write it down to polish the syntax.

Use of these principles helps the computing student who has learnt another paradigm such as structured programming. Such a student often has little difficulty learning the syntax of an object-oriented language but does have considerable considerable difficulty in learning the paradigm, or idiom, of object-oriented programming. Code is still "structured" even though it is written in an OO language.

The requirements of the aural-oral educational principle are
- meaningful situations
- role play where each and every member of the group listens and speaks the language - utterances are logical entities in the language
- emphasis on low level semantics and syntax is de-emphasised - an authority on the correct use is available to guide - the students come to "own" the conversation and - follow up reading/writing is done that corrects low level semantics and syntax within a meaningful situation

Where students come to foreign languages with an understanding of suitable meaningful situations (e.g. booking a hotel room) computing students do not come to Object Oriented Technology already knowing a meaningful situation. This is overcome by using a standard format for the development of a program every week. The students quickly learn what is expected at each point so can formulate contributions.

The students as a group then develop each object description. One student acts as scribe on the whiteboard. Where possible they contribute by writing the next step down. However as they usually cannot do this, the class contributes. In doing so, each student is encouraged to talk in logical syntactic units e.g. a statement. Other students are then listening. The role of the tutor is to encourage the students to follow an object oriented approach by rewarding good usage. (Care must be taken not to discourage bad usage - rather the student is encouraged to "improve" their contribution). When the group is happy, the accepted solution is written down.

The students come to own the resultant solution because as many decisions as possible are left to them. Some of these are decisions on the conduct of the class and some on the resultant program. For example, the contribution of the scribe is limited to one meaning item e.g. an object in an object diagram or a statement in a method. At that point the whiteboard pen is passed onto another student to act as a scribe. It is left to the student to decide the next scribe. (The sociology can be quite amusing, to onlookers, if there has been tension between the scribe and another person in the class). Other decisions that are group decisions are class, variable and method names.

The students then implement the solution in the practical where low level semantic and syntactic issues can be dealt with.

The aural-oral principle applied to the lecture-tutorial-practical pattern
- is most appropriate at the start of programming
- allows students to rapidly change strongly-held beliefs about the "correct" programming paradigm
- tends to cover material more slowly than other instructional patterns
- requires an authority so is teacher labour intensive; program development groups should not exceed 12 - is unusual so often needs considerable training of tutors

The first six weeks of a semester using these patterns are documented below. Each step constrains the actions and vocabulary of the next step.

= = = = = =

This is an implementation of the EDUCATIONAL PARADIGM FACTORY PATTERN
using the aural-oral method on the LECTURE-TUTORIAL-PRACTICAL PATTERN

Week 1
Lecture
Introduction to
- Objects and messages.
- Objects and object classes.
Smalltalk
The Smalltalk programming environment
- The Transcript window
- Browsers, The Class hierarchy browser

First steps in designing and using a program

Assignment
Draw a smiley face on the Transcript

Tutor Notes
Each tutorial is to strictly follow the problem, object identification, use case description, use case code and message tracing. After this week you will add the class description graphics and the class description code.

This week you will have to strongly lead the group. You should be able to get reasonable group interaction in selecting the code to draw the smiley. Encourage them to consult the class hierarchy browser for method descriptions. There will be no class descriptions as the students will be using the Pen class.

Week 2
Lecture
designing a solution to a problem
finding objects, their attributes and actions
tracing messages
implementing object descriptions
expressions and statements
object contents
description of the class of objects
class hierarchy browser
the display of a class description
entering instance variables, methods

Assignment
Draw a face that can either smile or frown; allow for the name of the person to be inserted below. Use a class for the Face

Tutor Notes
This week you will need to introduce the rest of the design process, namely the class design and the coding process.

You probably will find that the scribe needs a lot of support. However because there is so much repetition from last week the other students should be able to design most of the program together.

Week 3
Lecture
Review of class descriptions
-getter and setter methods
getting data from the display - prompter
windows
strings and string operations
putting data on the Transcript window - nextPutAll
printString as an architecture feature
some comments on initialising and updating

Assignment
Your company supplies a monopoly so you have a single customer. Provide a class description of the customer that allows you to store and update the customer's description. The customer has a name, email address and a phone number.

Input is to be done in a user-friendly manner that allows for checking of input and re-entry of errant input. -names are to be strings of characters -addresses are to be strings with no spaces and at least one @ character -telephone numbers are to be LargePositiveIntegers. Tutor Notes Students should be fairly easily following the design process but you will need to still be encouraging students who are diffident about speaking in public. Students are not expected to use loops this week.

Week 4
Lecture
Getting data from the display - message
windows and menus
strings and string operations
conditional statements
some comments on user friendliness
well formed loops

Assignment
{This is to produce a similar list} maintenance program as last week. However is is to be modified to provide user-friendly input that allows for "backing out" of every loop, checking of input, and re-entry of errant input.

Tutor Notes
This week the design process will be quite similar to last week so students should be taking command of the design process.

Week 5
Lecture
blocks
attributes of collections
Bags, common methods
terating through a bag
holding a bag in an instance variable
ordered collections
sorted collections
reuse of code

Assignment
The monopoly has now broken up so you now have many customers. Provide a program that will enable you to input and update the company customer list. Each customer has a name, email address, and phone number. Assume that no two customers have the same name so store the customers in a Bag. Allow for an alphabetical listing of the customers

Tutor Notes
It is important that students use the Customer class as a "library" class, knowing only its interface.

Week 6
Lecture
dictionaries
design issues related to keys
arrays
iterating through collections
class methods
check digits and some ways to implement

Assignment
Reimplement the customer list so that each customer is provided with a unique customer number. Each customer number is to be of the form d1d2d3d4c where d is a digit and c is a check digit. c is checked on input, is not stored but is generated on output. Its value is (7 * d1 + 3 * d2 + 5 * d3 + 2 * d4) mod 11. Provide a way to list customers alphabetically so that customers with the same name are listed in ascending customer number order.

Tutor Notes
Given the strong lead in lectures this week there should be some discussion as to the appropriate location for the generation of customer numbers and the checking of check digits. Encourage discussion and draw out the implications of having Customer class methods, CustomerList methods, and even CustomerList class methods. You may even get the good suggestion that they are appropriate placed in class methods in a separate CheckDigit class.

Week 7
Lecture
parts
polymorphism
inheritance

Assignment
Expand the customer listing so that customers can have email addresses (1 line), fax numbers (1 line), or postal addresses (3 lines). Allow the telephone numbers to be either internal extension (5 digits), standard Australian (area code 2 digits, then 4 digits space 4 digits) or short Australian (area code 2 or 3 digits, then 2 or 3 digits, then 4 digits). Provide a listing an additional listing where each entry is preceded by a green smiley face if the address is email, a red smiley if the address is a fax number and a blue frowney if the address is snail mail.

Tutor Notes
Each of the attributes for the customer can be placed in a tree of the form superAttribute, subAttribute1, subAttribute2, and subAttribute3. The amount of inheritance possible varies so while students will benefit from the similarity, you should still get some debate on the best location of methods.

Pedagogical Pattern #27
ETHOS
(Version 1.0)
Klaus Quibeldey-Cirkel
University of Siegen
Department of Electrical Engineering and Computer Science
D-57068 Siegen
Germany
quibeldey@ti.et-inf.uni-siegen.de

ETHOS is both an acronym for a structure of five different elements and a concise mnemonic aid. It represents a universal pattern for teaching the different facets of a wide ranging engineering subject. ETHOS reminds you that a solution to an engineer's problem commonly comprises Economic, Technical, Human, Organizational, and Social aspects.

INTENT
Structures a presentation, a lecture, or a manuscript as a whole. Helps to comprehend a manifold subject matter in its entirety.

MOTIVATION
You want to draft an introductory course about object-oriented software engineering, for example. The subject matter is to be taught in its whole spectrum avoiding pedantic and boring lectures. You choose aspects you want to elaborate upon for a longer period of time. In a way, you are looking for some pedagogical "spotlights" to focus the student's attention to the principal aspects of the teaching matter. Your motive can be outlined as follows:

You want:

- to give variety to your lectures;
- to take account of all important aspects;
- to follow a red thread where to line up your lectures supporting cohesive learning;
- to widen the student's perspective to interdisciplinary aspects.

APPLICABILITY
The subject matter should be one of engineering, e.g. a method for analyzing, designing, and implementing large-scale systems. It is important that economic and technical aspects are present.

Check if one or more of the following points apply to your problem:

- the subject matter involves a "paradigm", i.e.
(1) a "higher principle" or way of thinking, typical of a certain discipline, but which cannot be clearly formulated and which manifests itself by examples, and
(2) a "disciplinary matrix" of opinions and values holding together a "scientific community" [Kuhn, 1970]);
- the subject matter comprises many and diverse aspects that you intent to teach in more than five sessions;
- you want to hold an introductory course, i.e. you don't intent to go into much details.

The pattern also applies to structuring a textbook or manuscript about a wide ranging theme.

STRUCTURE
As an acronym, ETHOS is strictly sequential (thus a test whether all relevant aspects are taken into account); as a reading instruction, chapters structured in the ETHOS fashion can be read sporadically in any order. The pattern's basic structure follows its initials:

E: economic,
T: technical,
H: human,
O: organizational, and
S: social aspects.
If several topics apply to the same aspect, subdivide the structure's individual elements by indexing, e.g. T1, T2 ,..., Tn.

CONSEQUENCES
- ETHOS allows kaleidosopical lectures, i.e. being arranged in a colourful succession, each one a self-contained unit within a wide spectrum;
- ETHOS favours breadth before depth, general knowledge before specialized knowledge;
- it supports cohesive learning;
- it permits continuous learning: even if some lectures have been missed, the student can follow the others, thus, ETHOS helps to encapsulate a lecture as a learning unit;
- with the manuscript being similarly structured, the congruence between lecture and manuscript will be hold, i.e. arbitrary cuts and context switches can be avoided;
- ETHOS provides a general framework where new topics (current developments, etc.) can easily be integrated without changing the lecture's basic structure;
- ETHOS presupposes a deep analysis of both the subject matter and its didactic; the importance of and relationship between individual ETHOS aspects have to be made explicit.

IMPLEMENTATION
Integrate the ETHOS aspects into the general structure of your course, don't let them stand for their own. For a concrete example, topics and contents of a course on object-oriented systems design are given:

Topics of lectures:

1. Overview: ECBS "Engineering of Computer-Based Systems"
2. Paradigms of Design in Computer Science
3. Complexity of Designing
4. Mastering Design Complexity
5. E: Industrialized Software
6. T1: OOx: Abstracting - Partitioning - Communicating
7. T2: OOAD: Foundations of Analysis and Design Methods
8. T3: OOP: Defining and Categorizing Object-Oriented Programming Languages
9. H1: Cognitive Aspects: Designing as Human Problem Solving
10. H2: On the Tripartition of an Object: Structure - Behaviour - Constraints
11. O: Management Aspects: Technology Transfer and Project Organization
12. S: A Science of Design
13. Looking Back: FAQ and course evaluation

Contents of manuscript:

1 Paradigm Shifts in Computer Science
Paradigm Shifts in the Large: Kuhn's Thesis.
Paradigm Shifts in the Small: A Time without a Method,
The Art of Programming vs. Software Engineering, The Human Factor, SA/SD vs. OOx.
Object-Oriented World Models: Executable Models, Scenario of Object-Oriented Designing.

2 The Problem: Mastering Design Complexity
"No Silver Bullet": The Descriptive Nature of Complexity, Complexity and its Dimensions, Design Complexity.
"Hopes for the Silver": The Magical Number Seven, The Architecture of Complexity, Divide and Conquer.

ETHOS Aspects of the Object Paradigm
3 ETHOS: E like Economic
On the Way to Industrialized Software, The Principle of Locality, Software Reuse, Standard Class Libraries.
Competitive Pressure: Productive Software Development, Software Quality.

4 ETHOS: T like Technical
Object-Oriented Concepts: Abstracting, Partitioning, Communicating.
Object-Oriented Applications: Analysis and Design, Programming Languages.

5 ETHOS: H like Human
On the Psychology of Object-Oriented Concepts: Designing as Human Problem Solving, Cognitive Structures, Scheme and Correction, The Contribution of the Object Paradigm.
On the Philosophy of Object-Oriented Concepts: The World of Ontology, An Ontological Object Model.

6 ETHOS: O like Organizational
Technology Transfer: Questions about the Technology,
Questions about the Interface between Client and Designer,
Questions about the Design Process,
Questions about Project Control, Questions about Staff Management.
Aspects of Management: Homomorphism between Process and Product, Lean Management,
Object Management.

7 ETHOS: S like Social
"The Science of Design": Creating the Artificial, Curriculum of a Science of Design,
The Contribution of the Object Paradigm.
Architectural Designing: Ideals of a Generalized Discipline of Design,
Good Designing from an Architectural Perspective,
The Contribution of The Object Paradigm.
An Ontology of Design: Deep Structure: States - Events - Laws,
Good Designing from an Ontological Perspective, The Contribution of the Object Paradigm.

A Excursions: Imagery, Classification, Inheritance vs. Encapsulation, "The Treaty of Orlando",
The Terminology of the Object Management Group.
B The Object-Oriented Method by Example: Analysis, Design, Programming.
C Tables: Literature, Persons, Glossary, Abbreviations, Index.

EXAMPLE INSTANCES OF THIS PATTERN
At the University of Siegen the ETHOS pattern has been applied to a half-year lecture on "Object-Oriented Systems Design" annually since 1994: http://www.ti.et-inf.uni-siegen.de/courses/oos/oos.html The manuscript of the lecture follows the same pattern [Quibeldey-Cirkel, 1994]: http://www.Teubner.DE/cgi-bin/teubner-anzeige.sh?buch_no=918

RELATED PATTERNS
In principle, any instance of the Alexanderian pattern form, i.e. Problem - Context - Forces - Solution, is a likely candidate for structuring a course or manuscript. Experiences of applying the pattern form explicitly are yet to be published.

RESOURCES NEEDED
None. REFERENCES
[Kuhn, 1970] Kuhn, Thomas S.: The Structure of Scientific Revolutions. University of Chicago 1970.
[Quibeldey-Cirkel, 1994] Quibeldey-Cirkel, Klaus: The Object Paradigm in Computer Science (in German). Teubner-Verlag, Stuttgart 1994.

Pedagogical Pattern #28
Using Design Patterns as a context in which to teach Fundamental Components of Object Oriented Systems
(Version 1.0)
Jane Huang
Governors State University
University Park, IL 60466 USA
ghuangj@govst.edu

INTENT

To expose students to the fundamental principles of good object-oriented design.

MOTIVATION

There are certain fundamental principles on which good object oriented systems are based. Experienced programmers are familiar with these principles and have found them to be necessary ingredients in the design of robust and reusable systems. Design Patterns Demonstrate how these principles can be implemented to solve specific kinds of problems, and therefore provide a rich context in which to teach these principles.

APPLICABILITY

This Pedagogical pattern can be used in any non-beginner type object-oriented course, to teach the fundamental principles of object-oriented design, or to demonstrate how these principles might be implemented in a specific programming language.

STRUCTURE

1. Select a Design Pattern that implements the Principle.
Determine the design principle that is to be focused upon, and select a design pattern that clearly and concisely demonstrates how this principle might be implemented within a specific context.

2. Discuss the Design Principle
Use a short discussion or lecture to explain the design principle in terms of its purpose and the expected outcome of applying it.

3. Present the Design Pattern
Demonstrate how the design principle has been implemented within this pattern in the following steps:

a) Select one of the following methods to introduce the design pattern:
A formal presentation using class and state diagrams.
The Concrete to Abstract Pedagogical Pattern.
The Incremental Role Playing Pedagogical Pattern.

b) Focus on the section of the design pattern that implements the principle. Observe how classes and objects collaborate to solve the problem.

c) Give an actual example, in which the design pattern has been implemented.

4. Work on a problem.
Introduce a simple design problem that can be solved using this particular design pattern. Divide the students into small groups, and have each group design a solution to the problem that utilizes the technique or pattern being taught, and uses the specified design pattern. The required components could include class diagrams, class interfaces, implementation code or any combination of these items that provides the optimum practice for the selected topic.

5. Present Solutions
As many groups as possible should be given the opportunity to display their solutions. One possibility is to assign each available blackboard to a group and have the groups simultaneously display their results on the board. Each group can then be given a few minutes to present key points from their solutions.

6. Discuss Solutions
There should be an open class discussion of the solutions that have been displayed. Each group should not only present their solution, but discuss how the underlying principles have been implemented, and the expected advantages of such implementation.

7. Individual Practice
The instructor can set a simple homework assignment that requires the students to individually design a solution to a given problem by focusing on the technique or principle being taught.

CONSEQUENCES

1. Provides students with the opportunity to collaborate with others to solve a problem, thereby fostering confidence in individuals, and encouraging listening skills.

2. Exposes students to the skill of applying a known solution to a given problem, instead of "reinventing the wheel".

3. Introduces fundamental Object Oriented principles, and provides students with the opportunity to design a simple system in which these principles have been considered.

IMPLEMENTATION

1. A Design Pattern must be selected that clearly illustrates the Object Oriented Principle that is to be taught without complicating the issue by being too complicated.

2. The examples used to illustrate the design pattern must be ones that can be easily understood by the class, and the group exercises that are set must be based upon problem domains with which the majority of students are familiar.

3. Group dynamics should be discussed with the class before the group exercises take place, so that each individual is able to fully participate in the process.

4. If this method is used on more than one occasion, the groups should be altered so that different people have the opportunity to work together.

EXAMPLE INSTANCES OF THIS PATTERN

Teaching principles of Object Oriented Design such as:
Favor Object Composition over Class Inheritance
Program to an interface and not an implementation
Strive for loosely coupled classes

Teaching Techniques of Object Oriented Programming such as:
Polymorphism
Methods of communication between different types of objects.

Pedagogical Pattern #29
Using Design Patterns to teach the concept behind a complex framework
(Version 1.0)
Jane Huang
Governors State University
University Park, IL 60466 USA
ghuangj@govst.edu

Intent
To introduce a design concept behind a complex framework or toolbox that students will be required to use, so that as the individual components are presented, the students can understand how they fit into the bigger picture.

Motivation
When students learn to use a framework such as MFC, they become confused by the seemingly endless number of classes and functions. Design Patterns that are identified within the framework can be used to create a frame of reference for the actual classes and member functions that the student must become familiar with.

Some topics are best taught by placing students in a situation in which they "discover" for themselves how something works. If that approach were used to teach a framework, then the students would start working with the framework, and as various classes were used, and function calls made, the student would begin to piece together the entire concept. For some students, this process can become very confusing as they fail to build an adequate internal visualization of how all of the pieces fit together. This pedagogical pattern addresses this issue by attempting to provide students with a broad picture into which they can reference the individual components.

Applicability
This pattern can be used when teaching a course such as Visual C++ in which the student needs to become familiar with MFC, or a Small Talk course in which the student needs to become familiar with MVC concepts.

Structure
1. Mine Patterns from the framework
The instructor must identify design patterns that are used in the framework, and determine if any pattern might be useful for teaching a specific topic.

2. Explain the Concept
Use the Design Pattern that has been identified as a context in which to teach a concept. (For example: the Document/View paradigm in MFC). Explain the concept behind such a set of classes. Use charts, diagrams and other visual aids to explain the concept. The students should become familiar with all of the classes involved, and the types of function calls each type of object might need to make. This level is for understanding concept only!

3. Describe the Actual Implementation Within the framework
Explain the actual class heirarchy and familiarize the students with the implementation of the pattern within the framework. The students should be introduced to real classes and member functions, so that they understand how the design pattern has been implemented in the specific framework they are working with. This material can be covered by a combination of a short lecture followed by a demonstration of a simple application.

4. Hands On Practice
A lab assignment should be set in which each student is required to develop a simple application using the features of the framework that have just been discussed.

Consequences
1. Exposure to a concept that can be applied to solve many problems, instead of merely learning the implementation of one framework.

2. Reinforcement of the learning process as the material is presented in two different formats, first as a concept, and secondly as an implementation.

Implementation
1. The instructor must be able to adequately recognize useful design patterns within an application.

2. As students learn in a variety of styles, this method is best implemented by a combination of lecture, visual aids, demonstration of actual code, and hands on practice.

Example Instances of This Pattern
Teaching MFC (Visual C++)
Teaching MVC (Small Talk)

Pedagogical Pattern #30
Fixer Upper Pattern
(Version 1.0)
Joseph Bergin
Pace University
One Pace Plaza
New York, NY 10038 USA
berginf@pace.edu

INTENT
To introduce students early to larger problems than they can develop themselves. To give students skill at critical analysis. To introduce error analysis and correction.

MOTIVATION
Students can benefit from seeing larger problems than they can solve at their current state of development. They also need critical analysis skills and the ability to evaluate programs, designs, etc.

APPLICABILITY
The pattern can be used in several courses and at several levels. It can be used very early in programming courses and in teaching analysis and design. It can also be used to show the overall structure of a solution methodology.

STRUCTURE
Students are given an artifact, such as a program or design. The artifact proposes to be the solution to a problem, but while generally correct, the instructor has purposely introduced flaws into the program, design, or whatever. The artifact should be fairly large and should contain a number of flaws. Most of the flaws should be simple and obvious to most readers. There should be one or two deeper flaws.

Students are asked to find and correct the flaws. They can also be asked to discuss the nature of the flaws found and the reasons for their changes.

CONSEQUENCES
This pattern allows students to actively work with larger solutions than they can develop completely themselves. They benefit since finding flaws in their own work is a valuable skill. In programming, students see lexical, syntactic, and semantic errors. In design, they can see the effect of incorrect partitioning of responsibility.

IMPLEMENTATION
It is important that the overall structure of the artifact be sound. If it is a program it should be well designed and written, with good choice of identifiers. If it is an analysis or design document, its overall structure should be sound with a clear map to the problem statement.

The best way to develop such an artifact is to start with an excellent solution to a problem and then doctor it by introducing flaws.

Follow up. Most such exercises cause the students to generate questions that can be a fruitful source for classroom discussion. If the instructor is careful to introduce certain flaws, the student can be led in a desired direction to further explorations.

EXAMPLE INSTANCES OF THIS PATTERN
This pattern has been used to teach
1. Beginning programming. Here the artifact is a program illustrating a number of syntactical constructs that have not yet been introduced in class. (It has been used as the first assignment.) The program can be large enough that its structure is not obvious. Two or three classes with several short methods each is about right. One part of the program might be more complex. Together with the driver, there should be three or so pages of code. The errors can be mostly syntactical and lexical, so that the compiler can find them. One or two semantic errors should also be introduced, so that the program does not perform as expected. More serious and perhaps for more advanced students is the failure to fulfill a precondition contract. Ten to fifteen errors is about right if most are easily caught.

Even a single class can be introduced that has a flawed public interface. Students can be asked to analyze the consequences of this in relation to the likely current and future use of the class.

2. Introduction to design. Here a problem is presented and a design for the solution. Six to ten major elements in the design is about the right scale. The design should have a few simple flaws, such as missing message paths or missing functionality within a class. Improper partitioning of responsibility in a small region of the design is relatively easy to introduce. One subsystem could be left out. If the design requires several documents, there might be an inconsistency between the documents. Five or six flaws is probably enough.

RESOURCES NEEDED
A problem and a well designed and implemented artifact that you can manipulate to provide the necessary errors.

RELATED PATTERN
None

Pedagogical Pattern #31
Audio Object Analogies Pattern
(Version 1.0)
Robert Biddle
Victoria University of Wellington
New Zealand
robert@mcs.vuw.ac.nz

GOAL:

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

AUDIENCE:

This resource is intended especially for students without any programming experience. However, it has also proven useful for more experienced students as well.

PRE-REQUISITES:

None. This idea specifically relates to students who have little or no programming experience.

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.

APPLICABILITY:

The basic idea of analogies is to help explaining an unfamiliar subject domain in terms of a familiar sample domain. This is a strong approach where the students are indeed familiar with the sample domain, and where the two domains do in fact correspond sufficiently well for explanations in the sample domain to provide illumination in the subject domain.

This firstly means that the audio analogies do require that students be familiar with audio components. This is very common, mostly because listening to music is a popular cultural activity, and so audio components are commonplace. Moreover, the analogy works with audio components from the viewpoint of a user of the components, and not detailed knowledge of audio technology is required. However, there may be students who are not sufficiently familiar with audio components, and for these students the analogy will not be helpful.

The correspondence between the audio component domain and object-oriented programming is strong enough to be useful, but like any analogy it is not perfect. The analogy works well for classes, objects, interfaces, encapsulation, and composition. It also works, though not as smoothly, for inheritance and polymorphism. The analogy begins to break down with regard to parameters and customisation, although useful points can still be made. There are difficulties in making sensible correspondences regarding the system flow: the object-oriented domain is typically seen as control-flow oriented, and the audio-system domain seems more suited to a data-flow orientation.

STRUCTURE:

The analogy is really a quite general idea, rather than a specific item. Moreover, it has no concrete aspect: there are no software components. There could be a set of model diagrams or transparency masters, but none are provided currently. The only current artifact is the paper "Explaining Issues in Software Reusability" cited below, which discusses the analogy in detail. Some of the key elements of the analogy are as follows:

Objects: Object identification concerns understanding the nature of an entity with an interface and behaviour. Entities in the audio component domain are easy to understand as they can usually be shown to physically separate, have an understood interface, and a known behaviour.

Classes: In discussing audio objects, different classes of objects can also be easily identified because of mass production of particular components, and interchangeability of kinds of components on the basis of behaviour. Moreover, this can then lead to a discuss of taxonomy, and what interchangeability really might mean.

Interfaces: The interfaces of audio components can either be human interfaces or inter-component interfaces. The human interface, switches, dials, and so on, can be used to explain the nature of an interface, where control of behaviour is facilitated in a limited way. More importantly, the inter-component interfaces can then be introduced in a similar way, describing plugs and matching sockets, tabs and tab-detectors, and so on, and explaining how these also facilitate control of behaviour in a limited way.

Encapsulation: The human interface of audio components allows an easy explanation of encapsulation, as audio components are usually physically encapsulated, except for the provided interface. It can be shown how this allows component integrity to be maintained, and implementation to be modified without modification of the interface or other components. This argument can then also be made for inter-component interfaces.

Composition: While audio components are typically encapsulated, they can physically be opened, voiding the assurances of encapsulation. However, this does allow the internal implementation to be understood, which typically consists of other components, such as transformers, processor chips and so on. The point can be made that such inner components can be used in various different audio components, and that a particular audio component is an encapsulated composition of a set of connected inner components.

Inheritance: The range of audio components can be detailed taxonomically, which might provide a first approach to explaining inheritance. But the real advantage of inheritance in practical programming concerns good understanding of the principles of component interfaces. Inter-component interfaces allow components to be connected in a useful but safe way, typically by the shape of plugs and sockets representing deeper internal dependencies. However, in some cases a new plug can conform to the shape of an existing plug, yet provide different behaviour, a stereo headphone plug conforming to the shape of a monaural headphone plug, for example. In this way, interface conformance leads to greater utility for the context component, such as a tuner, which can be listened to in stereo or monaural sound. Interface conformance is the essence of inheritance as subtyping, which is the real advantage of inheritance.

CONSEQUENCES:

Use of this approach makes it easier to explain object design principles to students who have no experience with program design, or the consequences of good and bad program design. They usually do have experience in using audio components, and can understand the consequences of good and bad design in that domain. The audio component design domain corresponds sufficiently well to the object oriented design domain that the students are then able to better appreciate issues in program design because of the analogy.

IMPLEMENTATION:

The analogy is useful when explaining several detail principles of object oriented design, and useful both in explaining the design principles in the abstract, when they are being introduced as a general concept, and also when discussing specific design issues.

When introducing a design principle in the abstract, the audio component domain can provide a concrete example with understandable implications, at a time too early for the students to really appreciate examples relating to program design. In this way the analogy helps introduce general principles by means of a specific example, at a time that would otherwise make a specific example problematic.

When later discussing a specific design issue, the students might still have insufficient experience to understand the consequences of various design decisions. Such students, quite reasonably, can be unhappy or unwilling to simply trust authority to dictate that certain designs are good or bad, and unable to determine the correct conclusion by themselves. The audio analogy has the benefit of providing concrete examples with understandable implications backed by student experience, rather than relying on acceptance of authority or understanding of principle. For example, to help a student understand why a particular design is poor, a similar design can be sketched out in the audio component domain, where the student will better see how the poor design leads to undesirable results.

RELATED RESOURCES:

The author does not know of any resources that are especially related to this idea. However, anyone knowing of material with a similar approach is invited to contact the author, who will be pleased to investigate and possibly provide references here.

EXAMPLE INSTANCES:

A favourite example of the utility of the analogy concerns a perennial student design decision. Every year, students design many classes with methods that must make some decision and report the result. Every year, some students print out the result, rather than returning it. Every year, these students resist the idea that returning a result is superior design, because in the instance they are considering, printing out the result is exactly what they want. However, we have had success in asking if they would consider purchasing a cassette player that came only with permanently attached headphones, or permanently attached speakers, or a permanently attached cassette! We make the point that indeed in some circumstances these might, surprisingly, indeed be justifiable. However, they must consider the consequences of design in light of reasoning on such a basis, considering future reusability as a key way of making design decisions.

Pedagogical Pattern #32
Spiral Pattern
(Version 1.0)
Joseph Bergin
Pace University
One Pace Plaza
New York, NY 10038 USA
berginf@pace.edu

NAME
Spiral

INTENT
To introduce topics to students without covering them completely at first viewing so that a number of topics can be introduced early and then used. The instructor can then return to each topic in turn, perhaps repeatedly, giving more of the information needed to master them.

MOTIVATION
Many fields can only be mastered by individually mastering a large number of different techniques that must interact. Students can get bored, however, if too much time is spent on details of one topic or tool while the big picture is not shown to them, and exercises are artificially contrived to illustrate arcane details.

APPLICABILITY
This pattern can be used in several courses, primarily at the early stages of the curriculum. It can be used (at least) in programming courses, analysis and design courses, and special courses in object technology. A variation of this pattern is often used in the compiler construction course.

STRUCTURE
To start, the instructor should extract a subset of the material covering several topics that interact. Only simple cases should be introduced at first. The instructor and class move quickly through the topics until an understanding of how the topics interact can be gained. Students then can work with the tool subset on problems. Then more of each of the original topics, with perhaps simple cases of new topics are introduced to deepen understanding of the topics and of their interactions. Students then work on a richer set of problems. This can be repeated as often as necessary.

CONSEQUENCES
Students will get a feel earlier for how the pieces fit together. A potential negative consequence for some students, at least, is that some of their questions (What if...?) may need to be deferred.

IMPLEMENTATION
The instructor must extract subsets of each of the many topics in which the tools introduced can work together in problem solving. Several, increasingly large subsets, must be designed. Problems using most of the features of each subset need to be designed. One way to design the subsets is to start with the problems and extract a minimal set of tools necessary to solve that problem and similar problems. The next larger subset can often be designed by thinking about how the original problem could be expanded and its solution generalized.

EXAMPLE INSTANCES OF THIS PATTERN
This pattern can be used to teach low level programming structure. For example integer data, assignment statements and simple forms of if and while can be introduced. Problem solving using these topics only can be introduced allowing students to solve simple programming problems. In the second cycle, more can be discussed on each of these topics (else clauses, infinite loops,...).

In analysis and design, simple analysis techniques and tools can be introduced (simple use-case) and then the class can move to simple designs (CRC cards). Students can thus get a feel for the whole process, solving simple problems. The second cycle can introduce simple features of more sophisticated tools as well as somewhat more complex problems.

In object technology courses, simple inheritance can be introduced an used before polymorphism (dynamic binding) is discussed.

RESOURCES NEEDED
The instructor needs a plan, showing the order in which the topics will be introduced and what will be deferred to later cycles.

RELATED PATTERN
Early Bird

Pedagogical Pattern #33
Mistake Pattern
(Version 1.0)
Joseph Bergin
Pace University
One Pace Plaza
New York, NY 10038 USA
berginf@pace.edu

NAME
Mistake

INTENT
To have students learn explicitly, the effects of errors.

MOTIVATION
We usually help students avoid errors, but they occur anyway. Students should have a way to explore the effects of errors so that they can recognize them by their effects.

APPLICABILITY
This is very applicable to the early stages of learning programming. Syntax and semantic errors are frequent and students need to become familiar with the messages produced by compilers and run-time systems and what they indicate about the program.

The pattern could also be used in an analysis or design course in which certain specific, but fairly common, errors are required to be part of the design. The instructor can provide a part of the design which is flawed in some way and the students are asked to complete the design without changing the instructor's part. (See the Fixer Upper pattern also.)

This pattern is often used in Database and Operating Systems courses where the students are asked to explore the conditions leading to deadlock, by specifically causing it. Similarly, in learning concurrent programming, students are often asked to write programs in which race conditions between processes lead to the corruption of data.

One especially useful technique is to ask students to make errors that, when they occur accidentally, are especially hard to diagnose.

STRUCTURE
Students are given an assignment in which they are instructed to create and run a program with certain specific errors. They are then asked to comment on the diagnostics produced and/or why no diagnostics were produced for the error.

CONSEQUENCES
Students become more familiar with errors and how to correct them. Having seen specific errors, they can learn to avoid making them in the first place.

IMPLEMENTATION
The instructor should carefully prepare exercises using this pattern and be sure to do the exercise before the class does, so that unanticipated occurrences can be prepared for and explanations of precisely what happened can be provided later.

Follow up. It is important that the students get a chance to discuss interesting things that occur while making these errors.

EXAMPLE INSTANCES OF THIS PATTERN
Several were given under Applicability, above. In addition, this pattern can be used effectively to teach students about pointers in languages like C or C++, by having them make all of the common pointer errors purposely. This particular use is somewhat dangerous on computers that have memory mapped i/o and unprotected operating systems.

One exercise from an old book, now otherwise forgotten, was to write a program that produced every diagnostic mentioned in the manuals for a given (Fortran) compiler. This is, not surprisingly, very difficult to do. Impossible, for some compilers, as the documentation and the compiler are not completely parallel.

RESOURCES NEEDED
Knowledge of common errors.

RELATED PATTERN
Fixer Upper

Pedagogical Pattern #34
Early Bird Pattern
(Version 1.0)
Joseph Bergin
Pace University
One Pace Plaza
New York, NY 10038 USA
berginf@pace.edu

NAME
Early Bird

INTENT
To teach the most important material, the "big ideas," first (and often). When this seems impossible, to teach the most important material as early as possible.

MOTIVATION
Students often remember best what they learn first. This can be both positive and negative, of course. Important (big) ideas can be introduced early, even if they can't get complete treatment immediately.

APPLICABILITY
This has very wide applicability to almost every domain. If design is more important than programming, then find a way to do design as early as you can. If functions are more important than if-statements in programming then do them first. If objects are more important than functions, then do them first.

STRUCTURE
A course is mined for its most important ideas. These ideas become the fundamental organizational principle of the course. The ideas, and especially their relationships are introduced at the beginning of the course and are returned to repeatedly throughout the course.

CONSEQUENCES
The most important things in a course or curriculum receive more focus from the instructor and the students. Students can be made more aware of what is paramount.

IMPLEMENTATION
Implementation is difficult. Often only simple aspects of an important idea can be introduced early. Sometimes it is enough to give important terms and general ideas. Some "big" ideas are thought of as advanced. It is difficult to introduce some of these early. Hard thought and preparation are needed. Sometimes a really big, but difficult, concept can be introduced incompletely. Then as other material that relates to it is covered, the relationship to the big idea is carefully explored.

EXAMPLE INSTANCES OF THIS PATTERN
Teaching objects first (or at least early). Teaching design first. Teaching concurrency first in operating systems. Teaching user requirements first in Database. Teach recursion before loops. Of course, these are my definitions of what is most important. You may disagree, but then it is your course, so discover and implement your own "firsts."

The book Karel the Robot, by Richard Pattis was designed with this pattern in mind as a way of teaching procedural programming. Its successor, Karel++, attempts to do the same with Objects.

RESOURCES NEEDED
Time and deep thought. Discussion groups with other educators who share similar ideas about the most important concepts in a domain are very helpful.

RELATED PATTERN
Spiral. Some things can only be taught when tightly coupled to other things. Spiral can help here.

Note: This pattern is actually recursive, as patterns themselves are a really big idea.

Pedagogical Pattern #35
Toy Box Pattern
(Version 1.0)
Joseph Bergin
Pace University
One Pace Plaza
New York, NY 10038 USA
berginf@pace.edu

NAME
Toy Box

INTENT
To give the students broad historical and technological knowledge of the field by letting them "play" with illustrative pedagogical tools.

MOTIVATION
While we are teaching programming, it is nice to let the students program with things that will teach them some simple ideas from courses that they will encounter later in the curriculum. Some of these things are complex, but with appropriate scaffolding, even beginning students can use and extend the tools appropriately. Students have to program with "something." Often it is just integers and floats at the beginning. It could be things more exciting to them and which teach them on a variety of levels simultaneously.

APPLICABILITY
The pattern can be used in several courses and at several levels. It can be used very early in programming courses and in teaching upper level courses as well.

STRUCTURE
Students are given a library of classes that can be used to implement some complex functionality. These are the building blocks. They then use them to build some artifact. Instead of programming with integers and arrays, they program instead with logic gates, for example.

CONSEQUENCES
This pattern allows students to actively work with larger programs than they can develop completely themselves. If the tools are chosen correctly, they can also gain breadth of understanding of the entire field. If the class hierarchy is well built it also serves as a good model for students building their own classes and hierarchies later, though the intent is not to teach OOP specifically.

IMPLEMENTATION
The instructor distributes a class library that implements the basics of some functionality. The students may either use this unchanged or extend it and use the extended version to build some project. Care must be taken that the hierarchy is soundly built, demonstrating excellent techniques, and excellent structure.

EXAMPLE INSTANCES OF THIS PATTERN
A set of classes that implement logic gates and circuits. Gates can be connected together to form circuits.

An assembly language simulator that lets students get familiar with goto/register programming without all the details of a real machine.

An extension to the above that shows some of the problems with concurrency. A set of classes that let students experiment easily with readers/writers conflicts, for example.

A simple game with complete information that plays against the user but learns from its mistakes.

A simple spreadsheet like program. The program can store "programs" in cells using the simple assembly language of earlier "toys".

A set of classes implementing a simple relational database that can be queried with a simple language.

Decker & Hirchfield's Analytical Engine was a good use of this pattern.

RESOURCES NEEDED
Fairly rich hierarchies of classes implementing the tools. This is labor intensive, but resources can easily be shared.

RELATED PATTERN
None

Pedagogical Pattern #36
Tool Box Pattern
(Version 1.0)
Joseph Bergin
Pace University
One Pace Plaza
New York, NY 10038 USA
berginf@pace.edu

NAME
Tool Box

INTENT
To let the students build a tool kit in early courses for use in later courses. If well thought out and guided, it can be a wonderful guide to reusable software. Students become apprentices in the same sense as young people once served as apprentices in medieval guilds. There they spent their early years building tools they would need if they were to achieve master status in the guild.

MOTIVATION
Students in later programming courses make use of knowledge from earlier courses, but in the past made little use of the actual programs built there. Having a personal tool kit of reusable software components can be a wonderful help in a difficult project. Building the tool kit stresses different, but important, skills.

APPLICABILITY
The pattern is used most heavily in the early programming courses, especially the data structures course. However, it can be added to as well as used in later courses such as database, AI, operating systems, compilers, and the like.

STRUCTURE
Student exercises have multiple parts. One part of each exercise is to build a general tool that might be useful in other projects and to take some effort in its proper formulation for reuse. The design for reuse must be explicit and must be discussed by the students and commented on by the instructor. Groups of students can combine individual designs of the tools, discuss the relative merits of each and then build a common implementation that improves each of the individual designs.

CONSEQUENCES
Students gain skill in the early courses building reusable components. To the extent that they fail, the lessons are reinforced in the later courses when they need to rebuild parts of the tool kit for use in the projects of those course. Languages supporting reusability need to be used. Most of these languages are either object-oriented or functional. Scheme, C++, Eiffel, Java, Ada are good choices. There are a few others such as Modula 3, Beta, Oberon, CLOS, and Standard ML. Languages supporting genericity (templates) are especially useful.

IMPLEMENTATION
Instructors can provide some tools (data structures and algorithms) in the form of class hierarchies or other libraries. Students complement this collection. Time should be spent by students and instructor evaluating student built tools for correctness, of course, but also for the potential for reusability. Instructors in later courses must be aware that students have these personal tool kits and should use exercises and projects that exploit the tool kits and permit their extension.

EXAMPLE INSTANCES OF THIS PATTERN
Kernighan & Plaugher's Software Tools books were a good use of this pattern. This book should probably be read by anyone who wants to implement this pattern. It shows how a high degree of reusability can be achieved with extremely simple tools.

Many data structures, with only slight modification, could be taken as early examples of this pattern.

RESOURCES NEEDED
Thought needs to be given in the design of the early courses as to what tools are broadly useful, but especially which tools will necessarily be useful in later courses. Thought should also be given to platform independence of the tools. The instructor needs a plan and must be able to provide implementations of those tools that the students will need, but will not build themselves. For example, the instructor can give a singly linked list and have students build a doubly linked list. Both would be included in the toolkit.

RELATED PATTERN
Fixer Upper can be used by the instructor to provide partially flawed tools for the students to comment on and repair.

Pedagogical Pattern #37
Computer Ad Face-off Pattern
(Version 1.0)
Jeanine Meyer
Pace University
One Pace Plaza
New York, NY 10038 USA
meyer@pace.edu

NAME
Computer Ad Face-off

INTENT
To make students apply their [new] knowledge of basic computer terms and to reason about benefits and trade-offs in specific products.

MOTIVATION
Students need to advance from memorizing terms to applying technical jargon. Students also need and appreciate the skills and knowledge necessary to understand a computer ad. Students also need to realize that they must determine the objectives and constraints associated with a particular purchase; there is no 'best' computer for all situations.

APPLICABILITY
This is an exercise for an early course in computing information systems, including a computer literacy course.

STRUCTURE
Students get into groups and compare computer ads. Each group selects the best ad for a particular purpose. Representatives from groups with a common purpose come to the board and present their choices. The class votes on the best.

CONSEQUENCES
Students see the actual application of concepts and terminology. Hopefully, students acquire some skepticism about product advertising and maybe even product development. Students practice some subtle reasoning. This exercise also serves to de-center the classroom, with the teacher not being the only authority. Students may volunteer special knowledge.

IMPLEMENTATION
Students are directed to bring in an ad for a personal computer. They are encouraged to bring in an ad with terms that they do not understand. In class, groups are formed. The first task is to look at all the ads and see if they understand every term. The teacher circulates and answers questions. It is not a disaster and may even be beneficial if the teacher does not know something and just guesses. It may be appropriate to offer extra credit to anyone who can bring in an explanation of a particular phrase for the next class.
The second task is for the groups to identify the customer. Possible choices are student, family, small business, frequent business traveler, and large company buying multiple machines. Groups identify the best choice. Representatives from similar groups then come to the board. They write the brand name/company for their product. They will start to write down a list of features, but they need to be stopped. The class is asked to say what is the most important single attribute. This can be a discussion that the teacher can direct more or less forcefully. The significant attributes are identified and the representatives write them down. The representatives may be allowed to argue their case. The class votes.

EXAMPLE INSTANCES OF THIS PATTERN
The pattern can be used for personal computers or auxiliary equipment such as monitors, printers, modems, scanners, digital cameras, etc.

RESOURCES NEEDED
Students access newspapers, magazines, and the Web.

Pedagogical Pattern #38
Class Concept Map Pattern
(Version 1.0)
Jeanine Meyer
Pace University
One Pace Plaza
New York, NY 10038 USA
meyer@pace.edu

NAME
Class concept map

INTENT
To engage students in the process of making connections between technical terms.

MOTIVATION
Students often view the set of technical vocabulary terms located at the end of a chapter as unconnected. By participating in the construction of a concept map, they are more likely to appreciate relationships. Students have relatively small and overlapping responsibility in this activity and so failure on the part of some students is not fatal to the whole exercise.

APPLICABILITY
This pattern can be used in many courses at different levels. However, it was designed for a core course in Computer Information Systems required for all undergraduates and taken mainly by first year students. It has some of the advantages of a seminar without relying on each student to produce.

STRUCTURE
Students are assigned individual terms from the selected chapter. The assignment is to bring in a definition or description in your own words of "your term" and then find two or three terms that relate to it. Define or describe them and the relationship. The relationship can be "similar thing", "opposite", "uses", "attribute", etc. (Students familiar with object oriented analysis and/or entity-relationship modeling can be expected to be precise, but the exercise has value with beginning students.) In class, the teacher starts off with an appropriate starting term and asks if anyone was assigned that term initially or used that term in a relationship. The teacher writes the terms and draws connecting lines on the board.

CONSEQUENCES
Students must think about their terms. They will hear other definitions. They can be prompted for more subtle distinctions. They see different relationships. The teacher can contribute to the exposition at the point where students are thinking about the subject. Students also are required to speak in front of the class, which is an effort for many, but the talk is short and focused.

IMPLEMENTATION
An efficient way to implement this pattern is to use e-mail to send the terms, giving the same terms to two or three students. In the core course, we collect e-mail addresses early in the term. The term can be put in the subject line of the e-mail and the body of the note can be identical for all messages. Students are told to check their mail on a particular day. In class, students need to be prompted to contribute even if their terms are already noted.

EXAMPLE INSTANCES OF THIS PATTERN
The exercise works well with any jargon-laden topic. Good topical areas in the core course are Storage and Communications.

RESOURCES NEEDED
An e-mail facility and for the class session a large blackboard or white board.

Pedagogical Pattern #39
Group Card Sorting Pattern
(Version 1.0)
Jeanine Meyer
Pace University
One Pace Plaza
New York, NY 10038 USA
meyer@pace.edu

NAME
Group Card Sorting

INTENT
To help students understand what is required to express a procedure, the complexities of concurrent versus sequential processing, and, specifically, to provide an introduction to sorting.

MOTIVATION
Students, especially beginning students, have little sense of what a procedure or algorithm is. They do not appreciate that each step needs to be specified. Students also tend to believe that there is only one way to do something. Concurrent operations are especially complex and this can serve as an introduction (and just an introduction).

APPLICABILITY
This pattern can be done as a general introduction in an introductory computing class or later in programming or data structures classes when the students have more background. In the latter case, everything would be more rigorous. The sorting of playing cards can be replaced by the sorting of something else, such as a class list or a set of numbers.

STRUCTURE
Students are put into groups. For card sorting, seven or eight works well. Students are told to determine a fast way to put shuffled cards in order, making use of the fact that there are multiple processors, that is, people with minds, eyes, and fingers, to do the work. Groups then present their methods.

CONSEQUENCES
Students must accept the fact that the teacher is asking them to be more specific than is their general pattern of thinking. The fact that the specificity is a real thing becomes apparent when they realize that there are different ways to accomplish the same task.

IMPLEMENTATION
The teacher distributes decks of cards and asks the students to shuffle them. The cards are described as props only. The teacher generally needs to emphasize that I do not need these decks of cards put in order. What I do need is for you to articulate a procedure that works effectively.

EXAMPLE INSTANCES OF THIS PATTERN

RESOURCES NEEDED
Decks of cards or other sets of objects to be sorted.

RELATED PATTERNS
This is related to a common classroom programming pattern of having the students act out an algorithm.

Pedagogical Pattern #40
Team Teaching Pattern
(Version 1.0)
Jeanine Meyer
Pace University
One Pace Plaza
New York, NY 10038 USA
meyer@pace.edu

NAME
Team teaching

INTENT
To work with another faculty member to offer a course.

MOTIVATION
A particular topical area may be too broad for one person to handle. Time requirements may be too much. This can be a way to explore a new field.

APPLICABILITY One prime generic class of application for this pattern is the use of technology, specifically multimedia, Web research, or Web production in a discipline such as English literature and composition or education or marketing. Another generic class is when one teacher handles the lecture/discussion for a subject and another handles the lab.

STRUCTURE
The patterns that I am familiar with have well-defined roles for each teacher. This relates to the key attribute of team teaching: the division of labor. A related issue is are both teachers in the room at the same time? In the application of technology to subject matter variant, I, the technology teacher and my "content" colleague are both in the computer classroom. For the education classes, there is no other venue. For the English and marketing courses, the class also uses a regular classroom for the "regular" instruction and I am often absent. For the lecture teacher/lab teacher pattern, we may visit each other but are not a constant presence. In all these cases, it is important that the teachers and the students understand the roles and yet also understand that it is one course, with the teachers conferring with each other regularly.

CONSEQUENCES
Team teaching does what is called "de-center" the classroom. The students seem to take over more responsibility for the learning when they see teachers learning from each other. Students also observe teachers (adults) grappling with issues and being truly involved in the subject matter. If there are problems with students, it is wonderful to have someone to talk with about the problems. With multimedia, the two teachers (and the rest of the class) constitute a real audience for the student work. In the application of multimedia or any technologies to a subject area, it is quite beneficial to show deference to the subject matter teacher. This reinforces the message that "content" is more important the technical glitz.

IMPLEMENTATION
For this topic, I will address the prosaic issue of compensation! See examples below. For the Beowulf course, I receive 1 credit for my load and my colleague 3. Note that she does give a full lecture to the class and has the major responsibility for grading. The other courses were/will be split evenly.

EXAMPLE INSTANCES OF THIS PATTERN
At Pace University, Dr. Martha Driver and I team-teach a course giving 3 core literature credits and one credit cs/is elective called: Beowulf to Lear: Text, Image and Hypertext.
Our web page is http://csis.pace.edu/grendel
Dr. Sandra Flank and I team teach a summer intensive 1-week course Introduction to Multimedia for the Classroom. I am taking over the technologist role and working with Dr. Karen Berger on Strategic Web Marketing.

Pedagogical Pattern #41
Assigning and Grading (short) Team Projects Pattern
(Version 1.0)
Jeanine Meyer
Pace University
One Pace Plaza
New York, NY 10038 USA
meyer@pace.edu

The requirement for students to work in teams for short, medium or long duration projects brings up many issues of teaching and learning. I hope others will contribute patterns on this topic. This pattern touches on a small number of techniques that I have used.

NAME
Assigning and grading (short) team projects (duration for one class session to 2-3 weeks)

INTENT
Team work is now recognized as something that should and can be part of the school experience since team work will be commonplace in most students’ careers. Team work In addition, team work can deepen the learning of subject matter because the projects can be more substantial. This may be especially significant in object-oriented design work though I suspect it applies to many disciplines as well.

MOTIVATION
Two related issues that emerge often with teamwork are how to assign the teams and how to give grades. In my classes, students tend to stick with people they know, which, for the most part, would be people exactly like themselves in terms of gender, age, ethnic background. I feel it valuable to mix the students up. I also seek to have mixed teams with respect to skills, both ‘level’ and type. My approach to the team projects is to give the project one grade and that would apply to all team members. To me, this most resembles the real-world model. It may be true that students contribute differently, but that also is the real-world. (Note: I have heard about what seem to be wonderful approaches for long term projects when there is a project to ‘fire’ a member.)

APPLICABILITY
These approaches apply to projects given for 1 or 2 week time periods, or even a project that consumes a single class time. recently because I forgot the dice, was to have someone flip a coin and produce a numbeunting off--this certainly separates groups sitting together or a very non-random approach in which I strive for balance across several attributes: my assessment of their standing in class (this is usually reduced to my taking the best students and the worst students and doling them out one to a group), gender, ethnic origin, age (again, I categorize students as being college age and older and make sure these are mixed). In longer projects, I may ask the teams to designate roles for each person. This would include giving a presentation in class. In shorter projects, I tell the teams to divide up the tasks any way that works for them, but that everyone must understand everything. I roll dice to determine who speaks for the class presentation on presentation day. In order for anyone to do this, the students generally spend time preparing props and charts. Everyone gets the same grade!

CONSEQUENCES
Students take responsibility for the inter-personal issues and project management issues. Students learn from each other. There is also the phenomenon that individual students may demonstrate unexpected talents.

IMPLEMENTATION
The class work sessions require me to do the group assignments on the spot so counting off or names out of a hat or using their ID numbers or e-mail numbers are best. For the non-random, "balancing" situation, I work on the assignments before class. I use rubrics for projects. Throwing dice to determine who presents is something students enjoy. An alternative tactic, which I used recently because I forgot the dice, was to have someone flip a coin and produce a number in binary. This was valuable as a review of binary numbers.

EXAMPLE INSTANCES OF THIS PATTERN
Group project to produce Web pages as part of introductory computer information systems class; group programming project; group data base design project; etc.

RELATED PATTERNS
Anything to do with team projects?

Pedagogical Pattern #42
In-Line Exercises (ILE) Pattern
(Version 1.0)
Kevin Morris Marler
Raytheon E-Systems Garland
Manager of Learning Services
Technology Transfer Center
marler@onramp.net

NAME
In-Line Exercises Pattern

INTENT
To provide motivation for attention by the students and immediate feedback on learning objects to the instructor by having the students perform engineering exercises by sitting in groups of three (possible one set of two due to class count).

MOTIVATION
Instructors often have a difficult time knowing the degree of task competency during the presentation of complex engineering processes like the creation of object oriented diagrams. The ILE pedagogy provides an approach for the instructor to present the method and process for each task within an object oriented methodology and then to test the students^Ň understanding before continuing to the next task. Keeps the class from moving on without all of the class understanding the material. Useful for teaching processes that rely on the correctness of understanding of the previous tasks.

APPLICABILITY
Use the In-Line Exercises pattern to adjust the level of material being presented to the level of understanding demonstrated by the students.

STRUCTURE
Task is presented:
Instructor presents the methods and processes required by the students to perform a task.

In-Line Exercises:
The students, team size of three, perform the task sitting in the same position that they were during the instructor's presentation. Alternatively, the method and process can be contained in the course materials that are distributed to the students along with a blank worksheet that contains part of the graphics required for the model.

Review of Exercise:
The exercise is then worked with the class on an overhead transparency. Alternatively, an individual or team can be asked to write their answer on the transparency.

Course adjustment:
Instructor can either return to the task to present it again with another exercise or go onto the next task with an increased understanding of how well the class is understanding their presentation.

Lab:
Students perform the task immediately with feedback. For adult learners immediate feedback is key to their understanding and confidence.

CONSEQUENCES
The ILE pattern:
- allows students to know if they are understanding the material being presented and to develop confidence in their abilities;
- encourages students to ask questions based on problems that they have in performing the task or additional question that arise from form/style, correctness, or completeness;
- allows the instructor to find-tune the level of material being presented to the capability of the students.

IMPLEMENTATION
Issues to consider:
- the instructor needs to be capable of performing the tasks and able to perform a rapid review of the models as the students prepare them. The exercise can be from work performed on an actual project or from another credible reference, the project or references solution can be presented and contrasted to the work performed by the students;
- the students will ask questions based on problems that they have working the exercise. A useful technique is to lead a discussion of how the students worked the exercise: what lessons-learned did they gain; how can they make it easier for themselves to work this task the next time.;
- keep the in-line exercises simple. A set of simple exercises has been used with the discussion of the one where the instructor observed the most difficulty.

RELATED PATTERN
(none so far)

EXAMPLE INSTANCES OF THIS PATTERN
This pattern has been used to teach (examples available from Raytheon E-Systems Garland classes):
- Systems Engineering Using Object Concepts
- Requirements with Verification and Validation processes

Pedagogical Pattern #43
Model Transformation (MT) Pattern
(Version 1.0)
Kevin Morris Marler
Raytheon E-Systems Garland
Manager of Learning Services
Technology Transfer Center
marler@onramp.net

NAME
Model Transformation Pattern

INTENT
To emphasis the relationship between models within an object oriented engineering process by creating an opportunity for students to present the UML diagrams that they develop within the context of the other diagrams.

MOTIVATION
Students are often taught each diagram without being taught how the diagrams relate to each other while in practice there is a high degree of correlation between the diagrams. The MT pedagogy provides an approach the emphasizes the transformations. Students are encouraged to make changes to models that they have previously developed to show that they are gaining an increased understanding of the system being designed.

APPLICABILITY
Use the Model Transformations pattern while teaching a process that contains a series of diagrams that contain information that relate to each other within a larger context.

STRUCTURE
Origin of the design is presented:
Customer operational concepts document, requirements lists, or customer needs assessment.
First transformation information is extracted:
Operation contexts should be extracted, if engineering is to begin with Use Case engineering.
First UML model is developed:
Use Case diagrams are prepared from the transformation information and verified back to the original source of the desired system.
Next set of transformation information is extracted:
From the Use Cases, system responsibilities can be extracted in preparation for finding classes.
Next model is presented:
Class diagrams are prepared from the responsibilities transformation information. Interaction diagrams have proven useful in related use case engineering and class modeling engineering efforts.
Repeats the "next" steps while working through all of the UML models.

CONSEQUENCES
The MT pattern:
- the degree of consistency between the drawings is increased due to understanding the information that ties the diagrams together;
- students are more aware of the impact of changes, they know if the change relates to transformational information and what other diagrams need to be updated;
- provides the instructor with the opportunity to discuss the management of change.

IMPLEMENTATION
Issues to consider:
- student teams can prepare their UML drawings on easel paper-sheets, a series of easels can be lined up across the front of the class room, students present each diagram by discussion the transformation information first. This allows the students to discuss changes to previous diagrams as they continue design from diagram to diagram while learning more about the system and capturing the knowledge as it is realized.

RELATED PATTERN
(none so far)

EXAMPLE INSTANCES OF THIS PATTERN
This pattern has been used to teach:
- Software Systems Engineering Object-Oriented Analysis and Design
- Transitions for UML modeling

Pedagogical Pattern #44
Responsibility Driven Class Development Pattern
(Version 1.0)
Douglas B. Smith
University of the Pacific
Department of Computer Science
Stockton, CA 95211 USA
dsmith@jarl.cs.uop.edu

INTENT:
To introduce students to object design concepts when developing commonly used classes.

MOTIVATION:
When encountering frequently used classes, the student is usually presented with the list of attributes and member functions, challenged to code the class and then write a program using the class. This does not develop object "thinking". The Responsibility Driven Class Development pattern teaches introductory object design concepts and reinforces object thinking.

APPLICABILITY:
Use this to develop classes used in introductory courses - strings, stacks, queues, lists, linked lists, graphs.

STRUCTURE:

1. Responsibilities: using the CRC card approach, determine what the class should know, what are its reponsibilities and its collaborators.

2. Create a UML diagram for the class and document member functions.

3. Identify and discuss "small" use cases to refine the class and develop member function parameters.
Does the class know enough, have enough responsibility to ... ? For example, in developing a list class, can we search the list for an item? can we add an item to the list? What data does the class need to receive to carry out the responsibility?

4. Implement the Class
Use analogy, visual, and abstract representations to motivate code development. Test the class with a test harness.

5. Use the Class on a significant use case.

CONSEQUENCES:
In the early courses where this approach is used, the students pick up the language and elementary object design techniques. With repetition, the students get comfortable with CRC cards, responsibility driven design, simple UML diagrams and the idea of use cases.

IMPLEMENTATION:
It's important to avoid over directing the initial CRC discussions. For the pattern to work, the instructor must avoid comments like "we must be able to push data on a stack - right?". Let the students come up with their ideas. If you then move to a text book (pre-designed) class, you can discuss how the responsibilities identified by the students are (or are not) met by the class in the text.

The students can work together to develop a test driver that exercises all of the classes responsibilities. This gives everyone a way to verify the implementation of the class before using it in a larger project.

EXAMPLE INSTANCES:
This pattern has been used effectively in data structures and algorithms courses to teach: Strings, Stacks, Queues, Lists, Search Trees, Graphs, Hashing

Pedagogical Pattern #45
Concept, Glossary, Problem, Analyze, Discuss, Design (CoG-PADD) Pattern
Version 1.0
Donald J Bagert
Department of Computer Science
8th and Boston
Texas Tech University
Lubbock TX 79409-3104
bagert@ttu.edu

INTENT:
To teach a new idea at the conceptual level and in an interactive manner.

MOTIVATION:
When being introduced to a new concept, students too often concentrate on the details, without looking at the high-level aspects of the problem. Also, for a student to properly appreciate a concept, a problem example need to be posed that is excellent for analysis and architectural design, but may be too large for detailed design and implementation in the classroom environment.

APPLICABILITY:
This pattern can be used to introduce any major computing concept, although it of course works better in some areas than in others.

STRUCTURE:

Concept: Introduce the new idea, using real-world analogies as much as possible. As the students questions related to their real-world experiences in this area. ("How do you..." "What if...")

Glossary: Giving the students a glossary of new terms related to a subject area is important. Not all of those terms need to be addressed immediately. Having each term, where possible, compared to something they have experienced before can be especially useful.

Problem: The students should then be posed a real-world problem that uses this concept.

Analyze: The students should then, in small teams, analyze the problem statement ("customer requirements"). The instructor can act as a mentor and/or customer during analysis.

Discuss: The students then share their analysis with the class, and the positive and negative aspects of these analyses are discussed.

(Note: The Problem-Analyze-Discuss segment can be done in several increments where appropriate.)

Design: The instructor can then discuss how a specification results from this analysis can be converted into an architectural design. This step can also be done interactively with discussion, and in increments, as was shown for the Problem-Analyze-Discuss segment. This step should NOT ordinarily follow with further steps in the life cycle.

CONSEQUENCES:
1. Allows the students to understand a new idea without worrying about the details.
2. Allows the students to appreciate the concept using a real-world problem example that is excellent for analysis and architectural design, but too large for detailed design and implementation within the constraints of the course.
3. Allows the students to work in small groups to solve a problem, which helps them to quickly understand a new concept.

IMPLEMENTATION:
A little more preparation time is generally needed, despite the fact that there is more student participation than normal. A glossary probably takes up most of this time. Finding a good real-world problem is also essential.

EXAMPLE INSTANCES OF THIS PATTERN:
CoG-PADD has been successfully used to teach the object-oriented paradigm, task-based concurrency, and the logic-based paradigm. The object-oriented instance is described in [1], although not precisely in terms of CoG-PADD. In this case, the "problem-analyze-discuss" segment is performed in increments. The creation of that instance, which led to the development of the CoG-PADD pattern, was inspired by a technique Alistair Cockburn uses to teach the object paradigm [2], which would best be described as an instance of a "concept-design-discuss" (where the "design-discuss" phase is done in several increments) pattern, if such a pattern exists.

REFERENCES:

[1] Bagert, Donald J. Object-oriented design resources for CS2. OOPSLA '97 Research Workshop on Resources for Early Object Design Education, Atlanta GA, 5 October 1997.
(http://www.bk.psu.edu/faculty/mercer/design/Bagert.htm)

[2] Cockburn, Alistair. Teaching OO design is teaching how to assess the design's future. OOPSLA '96 Research Workshop on Teaching and Learning Object Design in the First Academic Year, San Jose CA, 6 October 1996.
(http://www.bk.psu.edu/faculty/mercer/design/16Alistar_Cockburn.htm)

Pedagogical Patter #46
Big Picture on a Small Scale (BPSS) Pattern
(Version 1.0)
Kerstin Voigt
California State University
San Bernardino, CA 92407
voigt@csci.csusb.edu

INTENT:
To focus the teaching of the object-oriented paradigm (OO) in weeks 1-4 of a 10-week quarter on Computer Science 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, inheritance and polymorphism.

MOTIVATION:
I strongly believe that the first 1-4 weeks (typically 8 1+-hour lectures with 3-4 lab sessions) are crucial in setting up students' mind sets with regard to OO. If objects are not introduced and emphasized as the artifacts whose manipulation is at the center of programming, the remainder of the course, and subsequent courses tend to suffer from the continued and repeated struggle to eliminate bad (e.g., non-OO) habits and misconceptions.

AUDIENCE:
The pedagogical pattern is meant to govern the very first weeks of teaching a a "Computer Science I" course. It is assumed that students are complete novices to the object-oriented paradign, and possibly computer programming in general.

STRUCTURE:
More discussion and insight is needed on what we could call "OO teaching" (how about OOT?). OO teaching should put objects and related concepts like aggregration, inheritance, and polymorphism in the foreground. That entails that these topic are introduced from the very beginning, instead of being banned to the final chapter (or even appendix!) of introductory OO textbooks. It also entails that the introduction of classes and objects -- when included in earlier chapters-- not be given in an overly gentle and timid fashion, only to be followed by chapters on functions, conditionals and iteration, before finally hitting the student over the head with a linked list (frequently, topics of inheritance and polymorphism are omitted entirely). First we go too slow, then too fast. No wonder, many students do not manage to get on track. I believe that more conducive to learning OO would be the presentation of topics in roughly this order:

1.Objects, Classes, object state
2.Aggregation
3.Object behavior, member functions
4.Inheritance
5.Polymorphism
6.Conditionals
7.Iteration
8......

The first exposure to functions will be in form of member functions ("what the object does"). Many students tend to have difficulties with functions initially; maybe the purpose of a member function will seem more intuitive and facilitate the understanding of the benefits of functions in general. Conditionals and iteration will be motivated as constructs that allow the specification of more richer object behavior. In other words: let's not practise conditionals and iteration in the body of a "big main", but in the body of a member functions; e.g., if-then-else comes in handy if a member function is to ensure that no illegal/ nonsensical object states be defined; iteration will allow the specification of object behavior that is repetitive.

If students are instructed from the very start to associate most (or, initally all) program behavior with small-bodied member functions belonging to objects, there will be less of the typical cramming of "everything the programs is to do" into a "big main".

CONSEQUENCES:
Students that will emerge with significantly greater familiarity, comfort and skill in object-oriented analysis (OOA), design (OOD) and programming (OOP).

The key to this style of teaching, will lie in its wholistic and practically "zero-alternative" approach to learning about the full spectrum of OO concepts in the earliest stages of learning to design and implement OO programs. Students will have embraced a sizable problem solving and programming paradigm by having been given the "big picture" (the OO paradigm) on a small scale (through small, intuitive examples).

Students will model data as objects because that's how problem-specific data were represented from the start. Students will express program behavior through member functions associated with objects because that's how objects were brought to life from the beginning. Students will use inheritance because that's how one could avoid restating the already established. And lastly, students will understand polymophism as a way of making adjustments to inherited behavior that has become inappropriate in the more specialized context.

IMPLEMENTATION:
The suggested approach to OO-teaching (I suggest: OOTch) essentially consists of not much more than a reordering of your typical Computer Science I and II textbook topics. Any instructor experienced with OO will be able to adopt this approach. The here presented suggestions address the first 1-4 weeks of OO teaching only. Beyond those weeks, a course may follow any one of numerous good textbooks on OO programming, with the added advantage that most likely more interesting examples than those presented in books can be dealt with. For example, no longer will sorting have to be taught as sorting an array of integers (how boring!), but sorting may be applied to an array of student_records or houses_for_sale, or just about any artifact whose object-oriented representation at this point comes natural to the students. What will be required of the instructor adopting this approach is the consistent and repeated reinforcement of the OO paradigm as a way of approaching the problem. For every new program, the same kinds of questions should be discussed in class:

What are the objects in this problem?
What are the important parts and properties of the objects?
Are these primitive parts (representable as int, char, ..) or are these parts objects in their own right?
What do these objects do? What behavior should they meaningfully exhibit?
Have we seen/dealt with/programmed objects before that are very similar? Do the new objects differ from those in that they have additional parts or properties?
If we let our new objects adopt the parts and behaviors from already defined objects, are the adopted ("inherited") behaviors still appropiate for the new objects, or should some behaviors be modified?

Answering those questions each and every time will have students practise looking at a problem with "OO eyes". It will naturally have them work with aggregation, inheritance and polymorphism. As the resource included below hopefully demonstrates, it is quite easy to come up with simple and intuitive examples.

The first four weeks of teaching Computer Science I in the suggested object-centered fashion are sketched out below. Several concrete object classes, specified in C++, are included as sample resources. Two things should be noted here. (1) You may view the use of C++ as a notation/shorthand to allow a less verbose presentation of the ideas. (2) You may view the bits of C++ code as parts of concrete class/lab exercises that demonstrate how in informal examination of objects in some problem domain is being translated into the syntactic constructs of a concrete programming language (Contrary to some, I believe that learning about syntax (which is generally agreed on as being the "easy part") does not have to be in the way of teaching design; the successful compiling and running of a program can be seen as valuable verification of one's design.)

Week-1: The class informally discusses the notion of an "object" as we know it from our daily experience with the physical world. The instructor may bring along some artifacts and let students describe them. Discover that many objects are composites, and are readily described in terms of their parts and properties. Looking ahead to subsequent lectures, students may also be instructed to discuss the kinds of behaviors (= things to do) that different kinds of objects are expected to exhibit. The discussion should be held at an informal level that allows all students to contribute.

Next discuss the notion of a "program" as a set of instructions that will have the computer manipulate data (= pieces of information = objects) to arrive at solutions to a given problem. A program needs to be informed of the kinds of objects (parts and properties) to manipulate. Since computers are not capable of understanding natural languages, objects are described to the program in a socalled programming language, C++ being one of many options. The previously informally discussed description of a type of object is now written out using programming language syntax. At this point, students are also taught that the programing language knows about several basic types of objects, from which all composite objects are to be built. These basic types are int, float, char etc.

An example for a resource for Week-1 defines a "house for sale" object that lists the number of bedrooms, square feet, asking price, address etc. as parts and properties. The corresponding class definition is kept simple in that all parts and properties are basic types of objects, and declared public (a minimal explanation of public should suffice at this point).

Week-2: The House_for_object is reexamined, and the discovery of other parts of the house is encouraged. Students will be led to suggest parts that are not representable as basic objects but are objects in their own right. For example, the house for sale can come with a garage (described in terms of how many cars it fits), and appliances (described as being of a brand name, and either powered with electricity or gas). Let students experience how new objects Garage and Appliances are defined in analogy to House_for_sale.

Effectively, the notion of aggregation has been introduced. In addition, it is fairly easy to lead over to the basics of encapsulation. At this stage, suffice it to say that parts and properties defining an object are precious and vulnerable to corruption (how about somebody indicating a negative number of bedrooms, or filling in some fantasy brandname?). Labeling parts and properties as protected will safekeep the state of an object.

Once the defining parts of an object have been rendered invulnerable, they have also been rendered inaccessible. Lead students to understanding that a carefully crafted interface will allow us to access and manipulate the parts and properties of an objects in a fashion that is intentionally restrictive; it allows only what is needed and meaningful, and disallows acts of corruption. The interface will initially be minimal and consist of exactly two member functions (= "behaviors") per part or property: one function that allows the assignment of values to the part, and one function that allows the access/retrieval of the part's value.

Week-3: Week-2 will have motivated the notion of a function. While other types of functions exist, no harm is done in letting students believe that a function is something that an object "does". In fact, the lack of any alternative to OO will counteract the development of non-OO programming habits from the start (... there will be no "big main()", and their won't be function calles other than calls to member functions; that in turn means that all data has been conceptualized and designed as objects).

Staying with the design of a House_for_sale object, students will find the interface too restrictive. Encourage the discovery of other meaningful member functions. For example, suggest that the house be able to avertise itself. A new member function House_for_sale::advertise() could print out a brief statement such as "This beautiful new home has 4 bedrooms and ...". Notice that beyond the syntax for class definitions and member functions, only standard input and output have to be taught which leads to inevitably very simple member functions. Next encourage students to discuss in more discriminate terms what kinds of houses may be up for sale. The notion of a "fixer-upper" may come up. Let students discuss the notion of a "fixer upper" compared to the earlier notion of a house for sale. Are there differences? Let students discover, that all parts and properties describing a house for sale, also apply to a fixer-upper, yet there is additional information that is typically provided along with the latter (e.g., the year it's been built, and whether it has lead paint and asbestos). Conclude Week-3 by having students write a C++ specification of Fixer-upper in analogy to the most recent definition of class House_for-sale.

Week-4: Discuss with students how it felt to be writing the specification for a class Fixer_upper. Did they find it repetitive at all? Would they want to repeat this experience for other types of houses on sale? Wouldn't it be nice, if you could tell the program that Fixer_upper is just like House_for_sale with some additional features? Having thus triggered their curiosity (and fed their budding discontent with the repetive exercise), they will be receptive to the notion of inheritance. A Fixer_upper can indeed by defined as a specialized subclass of House_for_sale, and not much additional syntax to express this relationship is needed. Demonstrate to students how easily the subclassing is expressed, and stress the convenience of having to add C++ specifications for only the additional features of the subclass.

Now examine the subclass Fixer_upper more carefully. It inherits all parts, properties and member functions from its superclass House_for_sale which is a good thing, except ... Point out that Fixer_upper also inherits member functions House_for_sale::advertise(), and that the function effectively advertises the object as "This beautiful new home ...". . This is clearly inappropriate for objects in the fixer-upper subclass. A fixer-upper should still be able to advertise itself, and the inheritance of this capability makes perfect sense. However, the messsage of the advertisement should be a different one. After students have appreciated the discrepancy, they will be receptive to the possiblity of redefining the message. Teach students that the inherited member functions advertise can be {\em overwritten} as part of defining Fixer_upper. The function retains the old (and entirely appropriate) name, but its body is changed to, say, "This affordable fixer-upper with great potential ...". And thus, at the week of Week-4, we have covered basic forms of polymorphism. The rest is reinforcement... Other standard topics of programming (conditionals, iteration, arrays, pointers, etc.) can now be taught in the usual sequence, but with the added motivation of allowing the expression of more sophisticated object behavior.