--CALL FOR PARTICIPATION--

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 this workshop 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."

Individuals interested in contributing to a "pedagogical patterns" publication are asked to submit a paper to this workshop, describing their success with teaching OT in the form of a pedagogical design pattern. A suggested format can be found in Susan Lilly's "Patterns for Pedagogy" article in the January 1996 issue of Object Magazine and in the four pattern examples which follow. The pattern does not have to be completely polished. An incomplete or a pattern outline will be considered, as long as it is a clearly documented success in meeting an essential problem for teaching OT. The purpose of the workshop is to polish and format these patterns, distribute them to all attendees, and then assemble them with other patterns for future publication.

Submission deadlines are August 5th (and 20th) 1996. (Electronic mail, ASCII format is preferred.) Participants will be notified of acceptance no later than August 20 (and September 1st).

Send submissions (email, ASCII format preferred) to:
Mary Lynn Manns
University of North Carolina at Asheville
Computer Science Dept.
Asheville, NC 28804, USA
Telephone: 704-232-5020
Fax: 704-251-6041
Email: manns@unca.edu

Workshop leaders:
Mary Lynn Manns, University of North Carolina at Asheville, USA
(manns@unca.edu)
Maximo Prieto, Lifia - Universidad de La Plata, Argentina
(maximo@info.unlp.edu.ar)
Phil McLaughlin, Staffordshire University, England
(P.McLaughlin@soc.staffs.ac.uk)
Helen Sharp, The Open University, England
(h.c.sharp@open.ac.uk)
Mahesh Dodani, IBM Object Technology University

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.

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

EXAMPLE INSTANCES OF THIS PATTERN
(will soon be provided by the author)

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