Intent:

Motivation:

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 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:

Consequences:

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:

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:

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

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