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 will be meeting at the end of November to spend a week working on the patterns. New "pedagogical pattern" ideas are always welcome. The leaders look forward to receiving more ideas before their meeting in November. Individuals interested in contributing should email ideas to Mary Lynn Manns before mid-November.

All the ideas on this page are 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 (see email address below).

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
Argentina
maximo@info.unlp.edu.ar

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.

INTENT:
Accelerate learning of detailed modeling concepts, as well as quality assurance techniques, while enabling the students to more actively take control of their own learning process. In addition, provide students with viable job-aids to use when back at work. (These job- aids are introduced in the training course and the students explore their use during class activities.)

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.

STRUCTURE:
1. 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.)
2. 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.
3. 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.
4. 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.)
5. 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:
1. The reading portion enables students to set their own pace.
2. Additional references in the reading provide students with pointers to material for further in-depth individual research as needed.
3. 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.
4. 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.
5. The common case study provides enhanced opportunities for the students to check consistency and completeness across models as well as within models.

IMPLEMENTATION:
1. 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.
2. 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.
3. The reading and critique portions could be done independently, prior to the course (but not so far in advance as to be forgotten).
4. Thanks to the reading done by the students, the instructor can focus the lecture on more detailed explanations and examples.
5. 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.
6. 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.
7. The activity description must be well defined to exercise most of the modeling concepts that are presented in the reading component.
8. 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.
9. 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.

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.

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

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

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.

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.

Intent
To clarify why a specific architecture was developed. To give the students a better understanding of complex software concepts by letting them behave as the objects involved.

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 of a solution for this problem. Often the solution seems to be very complicated at the first glance, but it gets easier after using it several times. Because you normally don't have this time during a course, you could increase the learning time by assigning object roles to the students.

Applicability
I have used this pattern only in industry in one week courses. Mostly I use it at the very end of the week, that means the students do have an understanding of objects. I have used a less complex pattern (just the role play) also at the beginning for explaining messages. In this way I apply it when explaining MVC, ValueModels, AspectAdaptors and AspectAdaptors using subjectChannels. As you can see from my sample applications I have used it only in Smalltalk courses, but it should also work for other oo courses.

Structure
Problem statement:
The instructor shows a problem out of the students world. If you don't have any in mind just take one everybody could at least grasp the idea of the problem. 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 - 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 being explained, so the students get an understanding 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 and 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 work. The instructions for the lab should be very detailed first with less detailed explanations while it's going on. Take for example, first a completed source example and let the students examine the code with the debugger. Now they can see how the messages are send 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, probably the students would state out that MVC seems to be a rather complicate thing for developing just a small application, or rather 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 part of the instructor to "make" this pattern really incremental.

Consequences
The Incremental Role Play pattern:
- shows students why somebody has introduced this 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 by the lab.
- should lead in the discussion phase to the next problem statement, so it's easy to introduce the next more complex concept.

Implementation
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. I try not to discuss different possibilities for a solution, because my goal is to introduce a specific concept like MVC and not what else could have been developed. And 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 for coming as soon as possible to the role play.
- The game should be played really 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 has to take care on the discussion that it leads to the next problem statement. I use to go from MVC - ValueModel - AspectAdaptor until AspectApator with subjectChannels.
- I'm not sure how this could work in a real huge group and how it will work in university.

Related Patterns
- Physical Analogy
- Concrete to Abstraction Pattern
- The Three Bears Pattern could be used
- Role Play is used

Example Instances of this Pattern
This pattern has been used to teach:
- The OO concepts, like sending messages
- Different patterns / architectures in Smalltalk
- MVC
- ValueModels
- AspectAdaptors
- AspectAdaptors using subjectChannels
(Hint for the role play: I 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. So I exchange the model by placing a different student on the chair.)

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

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)

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.

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.

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

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)

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.

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.

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.

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.

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.)

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.

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.

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.
* 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)

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 either:
* because there is insufficient time to study the full range of issues thrown up
* because there is insufficient information to complete the exercise
* because 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. Misused, however, or overused the pattern can destroy a learner's confidence in what she or he is learning. The pattern carries a health warning!

IMPLEMENTATION
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 issued 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 competences.

EXAMPLE OF USE
This pattern is used in the teaching of a Final Year Object-Oriented Development module at De Montfort 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 tp 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 modelling 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 grows. 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 parellelism 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 behaviour) 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 realise 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 1996]

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.

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)

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).

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.

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.

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.

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 format in the sections shown in the patterns above. (Thanks to Steve Houk, an academic and industry OO educator, for submitting the following draft of this pattern which he uses in his classroom.)

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.))