Pedagogical Patterns:
Successes in Teaching Object Technology
The process of training, retraining, and, most of all, educating people in object technology is an ongoing challenge which has many unanswered questions. While many good pedagogical ideas are presented at OO conferences and published in proceedings and journals each year, very little has been done to collate the effective practices of many OO educators into one publication. The purpose of the pedagogical patterns project is do just that, to create a publication which is similar to what Susan Lilly (in 1/96 Object Magazine) refers to as "reusable pedagogical design patterns."
According to Lilly, a pedagogical pattern should be repeatable and easy to adapt. Each pattern should be described in a way that allows it to be easily "instantiated" for different lessons by different instructors. However, patterns do not need to be new or original. Lilly compares this to the Gamma et al. "Design Patterns" book, as follows: "The largest contribution of the 'Gang of Four' book is the documentation of patterns that have been proven to work, not the invention of the solutions. What makes patterns useful is their ability to communicate proven solutions to common problems."
Most of the pattern ideas on this web page (many in first version) have been collected as part of three workshops held at ECOOP'96 (in Linz, Austria), TOOLS USA '96 (in Santa Barbara, California), and OOPSLA'96 (in San Jose, California). In addition, potential patterns were collected during a fourth workshop, held at the OT'97 conference this past April in Oxford, England. There was also a large amount of interest generated after a short Educators' Symposium presentation and Birds-of-a-Feather session held this October at the OOPSLA'97 conference.
The project leaders met at the end of November in Argentina to spend a week working on analyzing and categorizing the individual patterns, drafting a more useful format for the patterns, and making plans for the remainder of the project. The individual patterns are now being recast in a new format, a large task which is expected to be completed by early March. These newly drafted patterns will then be presented for review in mid-March at a patterns language conference (ChiliPLoP). In April, the fifth pedagogical patterns workshop will be held at the OT'98 conference in England.
From the feedback acquired from participants at the pedagogical patterns workshops and those who have provided feedback in other ways, a new format for the patterns has been drafted and is open for review. This format contains the following sections:
Note: Think of the above three sections in the following way: "I want to (the intent), using (the idea), because (the motivation)."
New "pedagogical pattern" ideas are always welcome. Individuals interested in contributing should email ideas to Mary Lynn Manns.
Project Leaders:
Mary Lynn Manns
University of North Carolina at Asheville
Asheville, North Carolina USA
manns@unca.edu
Helen Sharp
The Open University
United Kingdom
h.c.sharp@open.ac.uk
Phil McLaughlin
The Bloomsbury Software Company
United Kingdom
p.mclaughlin@soc.staffs.ac.uk
Maximo Prieto
Lifia - Universidad de La Plata
JP Morgan
Argentina
maximo@info.unlp.edu.ar
I. One of the challenges is expressed:
Students experience interference from procedure-oriented concepts they
already know. As a result, there is often more interference than
reinforcing.
II. Potential solutions are brainstormed:
#1 The instructor can make comparisons for students.
#2 Or, the instructor can attempt to make students think in an object way
from the beginning by postponing answers to students' inquiries regarding
how their present knowledge (e.g. procedure-oriented) compares to OO.
#3 Or, the instructor may wish to lead students through the design of a
system in first a "traditional" way and then in an OO way.
III. A pedagogical pattern is drafted from one of the three
potential
solutions:
Solution #3 was formatted into the first draft of a pattern, as
follows:
1) Students design and implement a project using a traditional
approach.
2) Instructor lectures on object concepts and suggests how this project
could
be repartitioned into objects.
3) Project is redone, by the students, using objects.
IV. The next step is to describe this pattern using the pedagogical pattern format. Since this was one of the first patterns contributed to this project, it is presently formatted in the old format.
NAME:
Design-Implement-Redesign-Reimplement (DIRR) Pattern
contributed by:
Steve Houk
Santa Barbara City College
Computer Science
721 Cliff Drive
Santa Barbara, CA 93109 USA
shouk@sisko.sbcc.cc.ca.us
INTENT
Explain new concepts and methods based on old concepts
MOTIVATION
It is often hard to get students to make the paradigm shift from
functional
programming to object oriented programming. The lecture-lab pedagogy
provides a "concept" and "use" approach which can prevent the student
from separating the "concept" from a specific "use". The DIRR pedagogy
provides "relearning" methodology for reinforcing new concepts. In this
pedagogy, the students are asked to design and implement programming
solutions using their current paradigm. This is followed by a discussion
of
how the solution can be redesigned using concepts from the new paradigm.
Finally, the students will reimplement their solutiona using the new
paradigm concepts.
APPLICABILITY
Use the Design-Implement-Redesign-Reimplement pattern to bridge the
gap from an old paradigm to a new paradigm.
STRUCTURE
Design: Students are given a programming problem and told to design a solution using their current familiar design methodology. The problem should contain components that can later be identified as redesignable in the new paradigm.
Implement: Students implement a solution to the programming problem using their current familiar coding methodology.
Redesign: After the students have implemented their solutions, the instructor leads a discussion of how the solution can be redesigned and repartitioned using new concepts from the new paradigm. Also presented are programming language features that support the new concepts.
Reimplement: The students redo the same programming problem using the new concepts from the new paradigm.
CONSEQUENCES: The DIRR pattern
1. Provides students with first hand experience of both the "old way" and
"new way" of developing solutions.
2. Students gain practical insight into how new concepts relate their
pre-established concepts.
3. Solving a problem more than one way often leads to deeper
understanding of the concepts being addressed.
4. Questions arising from the students will tend to focus on the "why"
things are done rather than on "how" they are done.
IMPLEMENTATION: Issues to consider
1. Double lab time required for each problem. However, second lab period
should be shorter since many of the "semantic" issues have been handled
by the students in the first lab.
2. Redesign discussions should center on how to repartition the problem
and not on "good" previous solution.
3. Stronger (ego) students may be frustrated by having to "redo" their
first
solutions.
4. Evaluation should focus on reimplemented solution. However, ignoring
first implementation entirely will reduce willingness of students to
provide
a wholehearted improved solution.
EXAMPLE INSTANCES OF THIS PATTERN
(Note: Although this "pattern" was conceived as a solution to the
procedural-to-OO challenge mentioned above, it is defined in a
general way so that it can have other instances -- so that
it can be used in other lessons by other instructors (e.g. converting
students
from one operating system to another, one language to another, one
development environment to another, etc.))
All the ideas on this page are presently in draft form. They still need quite a bit of work. Therefore, the project is soliciting feedback and ideas. Comments or further ideas can be emailed to Mary Lynn Manns.
The first group of patterns shown below is in the recently revised format described above. The second group is the collection of ideas in the older format (these are presently being redrafted into the new format).
Reading, Critique, Lecture, Activity, Presentation with discussion (RCLAP)
originally submitted by:
Mary Gorman & Susan Burk
American Management Systems Training Services
300 Chapel Road
Manchester, CT 06040 USA
mary_gorman@mail.amsinc.com
susan_burk@mail.amsinc.com
INTENT:
To accelerate the learning of detailed modeling concepts and quality
assurance techniques
IDEA:
This combination of elements will result in accelerated learning.
MOTIVATION:
The skills needed to build detailed, accurate and consistent OO work
products can be difficult to pinpoint and learn. At times, the modeling effort
may seem more like art than science. This pattern provides a means for an
individual to initially assess his/her current proficiency (through reading and
a critique of sample work products) and then offers a means to increase
his/her proficiency through the exploration of additional detailed concepts (in
the lecture, activity, and presentation portions).
APPLICABILITY:
The student must have a sound foundation in object-oriented analysis
concepts (gained in a training environment or through detailed reading). In
addition, students should have had at least four weeks applying basic OO
concepts in a work environment. The pattern can be applied to a variety of
OO models, such as the use case model, the object model, the state transition
diagram, the object interaction diagram, etc.
CONTRAINDICATIONS:
None identified yet
STRUCTURE:
.Reading: Each student reads the course material independently. The material provides details on the type of model and its associated work products, a detailed explanation of the modeling concepts, steps in how to build the model, additional references and quality assurance guidelines. (AMS has organized the reading materials and job-aids in a handbook format, which serves as a ready reference for the students after the class. The OOA Analyst's Handbook focuses on three views: project management topics, practitioner needs and the quality assurance aspect of building models. The project management view is a summary of what to build, examples of the models and the roles and responsibilities. The practitioner's view provides details in how to build the models. The quality assurance view contains rules that define the object-oriented correctness of the models.)
.Critique: This individual activity requires the student to study a sample model and determine its completeness and correctness. The student uses the reading material as needed, especially the quality assurance guidelines, and considers how to fix/improve the model. Alternately the critique sample could be two options the student appraises to select the better alternative or if needed, to build a third model. It is an opportunity for the student to evaluate his/her proficiency to probe the details of a model, find problems, and define appropriate solutions.
.Lecture: In a group setting the instructor builds on the reading material, providing additional examples and explanations, engages the students in discussion, answers questions that may have been raised during the individual reading and critique activities and summarizes the students' critique findings.
.Activity: The students, in small groups, use the reading materials and other job-aids to build a model to fully explore the reading and lecture concepts. The instructor serves as a mentor to the teams. Each model reflects an aspect of a single case study. This case study is a common thread throughout the class. (The case study is also extended in other follow-on training courses.)
Presentation with discussion: Each group presents its results to the class. The other groups use the quality assurance guidelines to verify the results. Comparisons of the different results provide additional insights.
CONSEQUENCES:
Students take more active control of their own learning process.
Students are provided with viable job-aids to use when back at work.
Additional references in the reading provide students with pointers to
material for further in-depth individual research as needed.
The critique requires students to reference reading material to identify
incorrect or inappropriate application of techniques. They become more
familiar with the material through frequent referencing. The critique serves
as a built-in test, enabling both the student and the instructor to assess the
student's grasp of the concepts and to pinpoint areas needing additional
instructional support. The common case study provides enhanced
opportunities for the students to check consistency and completeness across
models as well as within models.
ISSUES TO CONSIDER:
The reading material must be clear, descriptive, and well organized into
appropriately-sized components without losing cohesion of the concepts.
This material may be customized to a particular environment, e.g. a company.
The material for the critique must be limited in scope, with the premises
clearly stated. Yet the critique should challenge the students with complex
variations of the modeling techniques. The critique examples must be
carefully constructed to encompass the appropriate variations. One should
not underestimate the amount of time needed to build the examples. The
reading and critique portions could be done independently, prior to the course
(but not so far in advance as to be forgotten). Thanks to the reading done by
the students, the instructor can focus the lecture on more detailed
explanations and examples. Occasionally, after critiquing the first model,
some of the students express a preference for critiquing in a team setting.
Those students can then critique in pairs or small teams, while allowing those
students who would prefer to perform the critique on their own to work
alone. Based on the students' critique results, the instructor may have to
adjust the amount of lecture time to ensure the class understands the flaws in
the sample models and the fixes required. The activity description must be
well defined to exercise most of the modeling concepts that are presented in
the reading component. The instructor should be prepared to seed the
discussion during the presentation with appropriate questions. Some of the
questions will be based upon typical student errors while the others will arise
from the instructor's on-the-spot application of the quality assurance
perspective to the students' models. The team activity can be customized to
the students' specific business domain. This requires pre-delivery definition
of the business area by the client and the instructor, to control
scope.
CULTURAL DEPENDENCIES:
None identified yet
RESOURCES NEEDED:
Not recorded yet
EXAMPLE INSTANCES OF THIS PATTERN:
This pattern has evolved as we have shaped and re-shaped our Advanced
Object-Oriented Analysis course yet it is not inherently restricted to
object-oriented modeling training. It could certainly be generalized and
applied to many other diverse training topics.
RELATED PATTERNS:
None indicated yet
originally submitted by:
Alan O'Callaghan
Chair, Object Technology Group
De Montfort University
School of Computing Sciences
The Gateway
LEICESTER LE1 9BH
United Kingdom
aoc@dmu.ac.uk
INTENT:
The Mission Impossible pattern is used to make the student suspicious about
their understanding of important OT concepts so that they continually
question them.
IDEA:
Learners occasionally need to be "shocked" into deeper thinking about what
they are doing in order to appreciate some of the subtleties. This is all the
more necessary when such ideas as "objects model the real world" can be
understood in an entirely naive way which disarms the learner in the face of
real problems when they occur.
MOTIVATION:
A fundamental problem with teaching OT, whether it is in a 15-week lecture,
tutorial and lab.-based course, or an industrial short course is that the
educator is inevitably forced into a mode whereby abstracting and
generalizing the subject into "key" concepts has the side-effect of
oversimplifying a rich, deep technology which is full of subtleties.
OT is, in software engineering practice, arguably concerned about
"programming-in-the-large" and about the structure of software systems. It is
difficult, if not impossible, to reproduce such systems (and therefore the
problems they exhibit) in the classroom. Key truths about OT, that
distinguish it as a paradigm from say "structured methods," are often given a
naive expression (notoriously Meyer's "Objects are there for the picking"
answer to the rhetorical question, "Where do I find the objects?"). This can
lead to the learner badly underestimating the intellectual effort needed to
master OO concepts. Students learn best from "hands-on" experience.
APPLICABILITY:
The pattern is best used selectively, after a logical block of learning in the
form of instruction, lectures, reading and hands-on work has been
encountered and conquered by the learner. The idea of the pattern is to
present the learner with a problem that the basic concepts do not appear
sufficient to solve, in order to provoke further questioning, exploration and
self-study. It works best in group work situations. The pattern can also be
used to form a link between the learning of basic and more advanced topics
(the advanced techniques being needed to master the "impossibility" of the
problem).
CONTRAINDICATIONS:
None explicitly identified, but misused, or overused, the pattern can destroy
a learner's confidence in what she or he is learning. The pattern carries a
health warning!
STRUCTURE:
A problem is presented which, at first look, seems to suggest a
straightforward solution. A complete solution will, however, require careful
consideration of a number of issues and will not normally be possible
because: there is insufficient time to study the full range of issues thrown up,
or there is insufficient information to complete the exercise, or no solution is
possible despite first impressions The contrast between first impressions
("simple problem!") and the result of some study ("a deeper, more difficult
problem than first we thought!") is crucial to the successful application of
this pattern. A brief summary (5 mins. maximum) by the educator explaining
why the problem was "impossible" is vital.
CONSEQUENCES:
If used appropriately, and successfully, the result is a wide-eyed learner
keen to explore the deeper recesses of the technology and the philosophies
which underpin it, including areas of controversy.
ISSUES TO CONSIDER:
The problem should be able to be presented in a short form, and yet be
"complete" in the sense of there being sufficient information for the learners
to begin their work There should be no more than 45 mins. work involved
before the learners can appreciate that there are issues which require further
explanation. There should be no need for a "final" solution to the problem.
Indeed for the best implementations of it there is no solution. Closure comes
with an understanding of the problem's "impossibility" not its solution.
It is probably best, for reasons of learners' self-confidence, to sandwich the
use of Mission Impossible between blocks of teaching which are aimed at
delivering measurable competencies.
CULTURAL DEPENDENCIES:
None identified yet
RESOURCES NEEDED:
Not recorded yet
EXAMPLE INSTANCES OF THIS PATTERN:
This pattern is used in the teaching of a Final Year Object-Oriented
Development module at DeMontfort University, Leicester, UK. The module
aims at preparing students for the application of OT in the "real world" of
commercial IT development where large-scale legacy systems and the issues
surrounding them abound. Students take quite quickly to the idea that OT
development is, in some sense, "seamless". Practical exercises reinforce the
notion that objects identified in some conceptual model of the problem space
can be mapped more easily into code than is the case with so-called
traditional methods. This can lead to a naive confusion between "analysis
objects" on the one hand, and code objects on the other. An exercise based on
an anecdotal example in [Cook 1994] is used to disabuse students of these
naive ideas, and to provoke discussion about the nature of the mapping
between objects in various models (e.g., analysis model, design model,
implementation model. The students are split into groups of 6-8 persons,
given a scenario and asked to present an outline conceptual model (i.e., a
modeling of the problem space), followed by a design model. The scenario is
as follows: The sky is dark. The ground is cold. All is silent. The sun rises.
The sky brightens. Birds sing. A cock crows. The ground is warmed. Grasses
grow. Typically, students do not complete the first part of the exercise. They
get bogged down because they attempt to apply concepts about program or
code objects to their modelling of the problem. In particular, they attempt to
discover "appropriate" methods and messages and apply them in a
single-threaded chain of cause and effect which (though suitable and indeed
necessary for a machine-based simulation) can only distort a real world
problem which is full of parallelism and chaos. The educator can prompt
fruitful discussion of the underlying issue (the difference between objects
that model mental perceptions of the world and those that implement machine
behavior) by posing simple questions in a timely manner: e.g., if a group has
decided that the grasses grow because of messages being sent from the sun,
ask in what order the messages are received and why the grass grows
unevenly etc. By the end of the exercise, timed to fit into a one-hour tutorial,
students realize that a relatively simple program (model the sunrise) becomes
tortuous and difficult if a naive notion of object is applied in both kinds of
model. Transformation is necessary. This is achievable by assigning
responsibilities to objects in the analysis model until it is complete (in the
sense of each analysis object's existence in the model being justifiable by
some responsibility), and then assigning new responsibilities and reassigning
responsibilities to fill in gaps in the causality chain in the design model,
before identifying invocations to trigger actions to carry out the
responsibilities. These invocation-responsibility mappings can then be further
transformed into messages and methods which are programming concepts,
not modelling concepts.
RELATED PATTERN:
Can be considered as a special variant of the Plan-Do-Reflect (PDR) pattern
[Lilly, S. 1996. "Patterns for Pedagogy" in Object Magazine 1/96.]
originally submitted by:
Jutta Eckstein
Integral Development GmbH
Germany
jeckstein@acm.org
INTENT:
To clarify why a specific architecture was developed. To give the students
a better understanding of complex software concepts.
IDEA:
Making the students behave as the objects involved in an architecture will
help them understand it better.
MOTIVATION:
Educators often teach students solutions for problems the students never
had. By explaining the problem first with an example out of the students
world, they understand that there is a need for a solution to this problem.
Often the solution seems to be very complicated at first glance, but it
gets easier after using it several times. This approach is essentially right
but it takes time. Since you normally don't have this time during a
course, you could decrease the learning time by assigning object roles to
the students.
APPLICABILITY:
This pattern has been used only in industry in one week courses, mostly at
the very end of the week (students do have an understanding
of objects). A less complex pattern (just the role play) has been used at
the beginning of the week for explaining messages. As you can see from the
Examples Instances section, the pattern has been used only in Smalltalk
courses, but it should also work for other OO courses.
CONTRAINDICATIONS:
None identified yet
STRUCTURE:
. Problem statement: The instructor shows a problem out of the students world. If you don't have any in mind just take one in which the problem idea is easily grasped, e.g. you want to develop a UI-application. So you define some business objects and you want to view these business objects in different UIs for different users, e.g. take a bar chart, a pie and a table. You can interact with every kind of view, e.g. fill out the table, grow a bar with the mouse, etc. Every change in the view should change the model and every change of the model should be seen in every view. Almost everybody should understand that we need a mechanism which is responsible for this behaviour (hint: dependency).
. Lecture: The architecture or rather the concept is explained, so the students get an understanding of how the problem is solved. If we take the example from above, just explain which classes build the MVC framework and how the dependency mechanism works.
. Role Play: Every student plays one part of the concept for getting a deeper knowledge of the theory of the architecture. Students see how the different parts of the concepts are all working together to solve a bigger problem. So here we need at least one student acting as the model, one playing the view and one for the controller. Messages go back and forth by throwing a soft ball between the students.
. Lab: Students complete a lab prepared by the instructor where they figure out how the concept works. The instructions for the lab should be very detailed first with less detailed explanations while it's going on. For example, present the students first with a completed source example and let the students examine the code with the debugger. Now they can see how the messages are sent and implemented in the "real world". A more difficult example would be to let the students develop a small application for themselves.
. Discussion: This should be a student-centric discussion where the students recover what they have seen during the lab. The instructor leads the discussion towards the next problem (often the students come up with the problem for themselves). Staying with the MVC example, the students would probably state that MVC seems to be a rather complicated thing for developing just a small application, or believe that a lot of code has to be reproduced for every application. See, we have the need for the concept of ValueModels. As you can see in the discussion phase it's the responsibility of the instructor to "make" this pattern really incremental.
CONSEQUENCES:
This pattern:
- shows students why somebody has introduced a particular software concept.
This means students understand the purpose of the concept.
- gives the students the opportunity to understand the concept from the
inside by playing a role in the architecture.
- deepens the experience from the role game with a lab activity.
- should lead the discussion phase into the next problem statement, so
it's easy to introduce the next, more complex, concept.
ISSUES TO CONSIDER:
- The problem statement should be enlightened from different sides, so that
every student will be able to identify the problem from his/her own
experience. Do not try to discuss different solutions, since the goal is to
introduce a specific concept like MVC and not what else could have been
developed. On the other hand, the students will get frustrated very
soon if they see that their solution is not of much interest. To
summarize:
- The problem statement is just an introduction to the concept.
- The lecture or theory itself should be as short as possible so one can begin
role play as soon as possible.
- The game should be played very close to the reality. On the other hand,
stuff which prolongs the game and is already clarified, should be omitted.
For example method lookup mustn't be ruled out. The instructor shouldn't be
afraid of playing the game. My experience is that, especially in industry,
the students are happy if they get a less abstract explanation.
- The lab should lead step by step from more basic things in the concept to
the more complex ones.
- The instructor must make the discussion lead to the next problem
statement. For instance, go from MVC - ValueModel - AspectAdaptor to
AspectAdaptor with subjectChannels.
- There is no experience about how this could work in a real huge group or
at the university.
CULTURAL DEPENDENCIES:
None identified yet
RESOURCES NEEDED:
Not recorded yet
EXAMPLE INSTANCES OF THIS PATTERN:
This pattern has been used to teach:
- OO concepts, like sending messages
- Different patterns / architectures in Smalltalk
- MVC
- ValueModels
- AspectAdaptors
- AspectAdaptors using subjectChannels
(Hint for the role play: Simplify the architecture and use one student as
the widget, one as the AspectAdaptor and one as the model. But the model
sits on a subjectChannel, here on a chair. In this way you can change the
model by placing a different student on the chair.)
RELATED PATTERNS:
- Physical Analogy
- Concrete to Abstraction Pattern
- The Three Bears Pattern could be used
- Role Play is used
Contributed by:
Joseph Bergin
Pace University
One Pace Plaza
New York, NY 10038 USA
berginf@pace.edu
INTENT
To introduce students early to larger problems than they can develop themselves.
To give students skill at critical analysis. To introduce error analysis and
correction
IDEA
Fixing a larger artifact than can be created by students is generally within
their grasp. It gives them a better sense of scale of interesting problems and
permits them to integrate a number of issues into the solution of a single
problem.
MOTIVATION
Students can benefit from seeing larger problems than they can solve at their
current state of development. They also need critical analysis skills and the
ability to evaluate programs, designs, etc.
APPLICABILITY
The pattern can be used in several courses and at several levels. It can be
used very early in programming courses and in teaching analysis and design. It
can also be used to show the overall structure of a solution methodology.
CONTRAINDICATIONS
None.
STRUCTURE
Students are given an artifact, such as a program or design. The artifact proposes to be the solution to a problem, but while generally correct, the instructor has purposely introduced flaws into the program, design, or whatever. The artifact should be fairly large and should contain a number of flaws. Most of the flaws should be simple and obvious to most readers. There should be one or two deeper flaws.
Students are asked to find and correct the flaws. They can also be asked to discuss the nature of the flaws found and the reasons for their changes.
CONSEQUENCES
This pattern allows students to actively work with larger solutions than they
can develop completely themselves. They benefit since finding flaws in their
own work is a valuable skill. In programming, students see lexical, syntactic,
and semantic errors. In design, they can see the effect of incorrect
partitioning of responsibility.
ISSUES TO CONSIDER
It is important that the overall structure of the artifact be sound. If it is a
program it should be well designed and written, with good choice of identifiers.
If it is an analysis or design document, its overall structure should be sound
with a clear map to the problem statement.
The best way to develop such an artifact is to start with an excellent solution to a problem and then doctor it by introducing flaws.
Follow up. Most such exercises cause the students to generate questions that can be a fruitful source for classroom discussion. If the instructor is careful to introduce certain flaws, the student can be led in a desired direction to further explorations.
CULTURAL DEPENDENCIES
None.
RESOURCES NEEDED
A problem and a well designed and implemented artifact that you can manipulate
to provide the necessary errors.
EXAMPLE INSTANCES OF THIS PATTERN
This pattern has been used to teach:
1. Beginning programming. Here the artifact is a program illustrating a number of syntactical constructs that have not yet been introduced in class. (It has been used as the first assignment.) The program can be large enough that its structure is not obvious. Two or three classes with several short methods each is about right. One part of the program might be more complex. Together with the driver, there should be three or so pages of code. The errors can be mostly syntactical and lexical, so that the compiler can find them. One or two semantic errors should also be introduced, so that the program does not perform as expected. More serious and perhaps for more advanced students is the failure to fulfill a precondition contract. Ten to fifteen errors is about right if most are easily caught.
Even a single class can be introduced that has a flawed public interface. Students can be asked to analyze the consequences of this in relation to the likely current and future use of the class.
2. Introduction to design. Here a problem is presented and a design for the solution. Six to ten major elements in the design is about the right scale. The design should have a few simple flaws, such as missing message paths or missing functionality within a class. Improper partitioning of responsibility in a small region of the design is relatively easy to introduce. One subsystem could be left out. If the design requires several documents, there might be an inconsistency between the documents. Five or six flaws is probably enough.
RELATED PATTERN
None
Contributed by:
Joseph Bergin
Pace University
One Pace Plaza
New York, NY 10038 USA
berginf@pace.edu
INTENT
To introduce topics to students without covering them completely at first
viewing so that a number of topics can be introduced early and then used. This
can get students working on interesting problems earlier as they have more tools
to use, though they have not, perhaps, mastered any of the tools. The
instructor can then return to each topic in turn, perhaps repeatedly, giving
more of the information needed to master them.
IDEA
This pattern results in the topics of a course being more fine grained, with
just enough of a larger topic introduced at each stage to permit problem solving
with other tools/topics which are also, as yet, not completely covered. For
example, "iteration" is a big topic. The "while loop" is a small topic,
especially if initially introduced with only simple loop tests. Yet the while
loop can be used effectively with other constructs to build meaningful programs
before iteration is understood in all of its aspects.
MOTIVATION
Many fields can only be mastered by individually mastering a large number of
different techniques that must interact. Students can get bored, however, if
too much time is spent on details of one topic or tool while the big picture is
not shown to them, and exercises are artificially contrived to illustrate arcane
details.
APPLICABILITY
This pattern can be used in several courses, primarily at the early stages of
the curriculum. It can be used (at least) in programming courses, analysis and
design courses, and special courses in object technology. A variation of this
pattern is often used in the compiler construction course.
CONTRAINDICATIONS
This pattern cannot be used in a small way. A commitment needs to be made to
it. If this is not possible or desirable, avoid it entirely.
STRUCTURE
To start, the instructor should extract a subset of the material covering
several topics that interact. Only simple cases should be introduced at first.
The instructor and class move quickly through the topics until an understanding
of how the topics interact can be gained. Students then can work with the tool
subset on problems. Then more of each of the original topics, with perhaps
simple cases of new topics are introduced to deepen understanding of the topics
and of their interactions. Students then work on a richer set of problems.
This can be repeated as often as necessary.
CONSEQUENCES
Students will get a feel earlier for how the pieces fit together. A potential
negative consequence for some students, at least, is that some of their
questions (What if...?) may need to be deferred.
ISSUES TO CONSIDER
The instructor must extract subsets of each of the many topics in which the
tools introduced can work together in problem solving. Several, increasingly
large subsets, must be designed. Problems using most of the features of each
subset need to be designed. One way to design the subsets is to start with the
problems and extract a minimal set of tools necessary to solve that problem and
similar problems. The next larger subset can often be designed by thinking
about how the original problem could be expanded and its solution generalized.
CULTURAL DEPENDENCIES
None as yet targeted, though this pattern may well work better with some
students than with others.
RESOURCES NEEDED
The instructor needs a plan, showing the order in which the topics will be
introduced and what will be deferred to later cycles.
EXAMPLE INSTANCES OF THIS PATTERN
This pattern can be used to teach low level programming structure. For example integer data, assignment statements and simple forms of if and while can be introduced. Problem solving using these topics only can be introduced allowing students to solve simple programming problems. In the second cycle, more can be discussed on each of these topics (else clauses, infinite loops,...).
In analysis and design, simple analysis techniques and tools can be introduced (simple use-case) and then the class can move to simple designs (CRC cards). Students can thus get a feel for the whole process, solving simple problems. The second cycle can introduce simple features of more sophisticated tools as well as somewhat more complex problems.
In object technology courses, simple inheritance can be introduced an used before polymorphism (dynamic binding) is discussed.
RELATED PATTERN
Early Bird
Contributed by:
Joseph Bergin
Pace University
One Pace Plaza
New York, NY 10038 USA
berginf@pace.edu
INTENT
To have students learn the effects of errors explicitly.
IDEA
Students, like professionals, make errors. Professionals generally know what
the indications of an error are, but students do not. Use of this pattern
explicitly teaches students how to recognize and fix errors. We ask the student
to explicitly make certain errors and then examine the consequences.
MOTIVATION
We usually help students avoid errors, but they occur anyway. Students should
have a way to explore the effects of errors so that they can recognize them by
their effects.
APPLICABILITY
This is very applicable to the early stages of learning programming. Syntax and semantic errors are frequent and students need to become familiar with the messages produced by compilers and run-time systems and what they indicate about the program.
The pattern could also be used in an analysis or design course in which certain specific, but fairly common, errors are required to be part of the design. The instructor can provide a part of the design which is flawed in some way and the students are asked to complete the design without changing the instructor's part. (See the Fixer Upper pattern also.)
This pattern is often used in Database and Operating Systems courses where the students are asked to explore the conditions leading to deadlock, by specifically causing it. Similarly, in learning concurrent programming, students are often asked to write programs in which race conditions between processes lead to the corruption of data.
One especially useful technique is to ask students to make errors that, when they occur accidentally, are especially hard to diagnose.
CONTRAINDICATIONS
This pattern can be over used. It is best used early.
STRUCTURE
Students are given an assignment in which they are instructed to create and run
a program with certain specific errors. They are then asked to comment on the
diagnostics produced and/or why no diagnostics were produced for the error.
CONSEQUENCES
Students become more familiar with errors and how to correct them. Having seen
specific errors, they can learn to avoid making them in the first place.
ISSUES TO CONSIDER
The instructor should carefully prepare exercises using this pattern and be sure to do the exercise before the class does, so that unanticipated occurrences can be prepared for and explanations of precisely what happened can be provided later.
Follow up. It is important that the students get a chance to discuss interesting things that occur while making these errors.
CULTURAL DEPENDENCIES
None.
RESOURCES NEEDED
Knowledge of common errors.
EXAMPLE INSTANCES OF THIS PATTERN
Several were given under Applicability, above. In addition, this pattern can be used effectively to teach students about pointers in languages like C or C++, by having them make all of the common pointer errors purposely. This particular use is somewhat dangerous on computers that have memory mapped i/o and unprotected operating systems.
One exercise from an old book, now otherwise forgotten, was to write a program that produced every diagnostic mentioned in the manuals for a given (Fortran) compiler. This is, not surprisingly, very difficult to do. Impossible, for some compilers, as the documentation and the compiler are not completely parallel.
RELATED PATTERN
Fixer Upper
Contributed by:
Joseph Bergin
Pace University
One Pace Plaza
New York, NY 10038 USA
berginf@pace.edu
INTENT
To teach the most important material, the "big ideas," first (and often). When
this seems impossible, to teach the most important material as early as
possible.
IDEA
Students need to see where they are headed. They need to see that detail
presented early in the course will relate to important ideas. Here we order
class topics in order of importance and find ways to teach the most important
ideas early.
MOTIVATION
Students often remember best what they learn first. This can be both positive
and negative, of course. Important (big) ideas can be introduced early, even if
they can't get complete treatment immediately.
APPLICABILITY
This has very wide applicability to almost every domain. If design is more
important than programming, then find a way to do design as early as you can.
If functions are more important than if-statements in programming then do them
first. If objects are more important than functions, then do them first.
CONTRAINDICATIONS
It may be a mistake to try to use this pattern with material that has clear
prerequisite ideas to the important ideas. This would be especially true if the
relationship between the prerequisite idea and the big idea is especially
subtle or if the prerequisites are especially difficult to master.
STRUCTURE
A course is mined for its most important ideas. These ideas become the
fundamental organizational principle of the course. The ideas, and especially
their relationships are introduced at the beginning of the course and are
returned to repeatedly throughout the course.
CONSEQUENCES
The most important things in a course or curriculum receive more focus from the
instructor and the students. Students can be made more aware of what is
paramount.
ISSUES TO CONSIDER
Implementation is difficult. Often only simple aspects of an important idea can
be introduced early. Sometimes it is enough to give important terms and general
ideas. Some "big" ideas are thought of as advanced. It is difficult to
introduce some of these early. Hard thought and preparation are needed.
Sometimes a really big, but difficult, concept can be introduced incompletely.
Then as other material that relates to it is covered, the relationship to the
big idea is carefully explored.
CULTURAL DEPENDENCIES
Professors need to be able to analyze deeply what are the consequences of
developing material in a particular order. It is often helpful here to have a
forum in which ideas can be discussed and refined. It is also often necessary
to develop your own materials, which requires time and effort.
RESOURCES NEEDED
Time and deep thought. Discussion groups with other educators who share similar
ideas about the most important concepts in a domain are very helpful.
EXAMPLE INSTANCES OF THIS PATTERN
Teaching objects first (or at least early). Teaching design first. Teaching concurrency first in operating systems. Teaching user requirements first in Database. Teach recursion before loops. Of course, these are my definitions of what is most important. You may disagree, but then it is your course, so discover and implement your own "firsts."
The book Karel the Robot, by Richard Pattis was designed with this pattern in mind as a way of teaching procedural programming (procedures first). Its successor, Karel++, attempts to do the same with Objects (classes first).
RELATED PATTERN
Spiral. Some things can only be taught when tightly coupled to other things. Spiral can help here.
Lay of the Land can be used to show the students an example of a big idea in action.
Note: This pattern is actually recursive, as patterns themselves are a really big idea.
Contributed by:
Joseph Bergin
Pace University
One Pace Plaza
New York, NY 10038 USA
berginf@pace.edu
INTENT
To give the students broad historical and technological knowledge of the field
by letting them "play" with illustrative pedagogical tools.
IDEA
Student exercises are chosen to give the students a rich set of experiences
about what can be done and what is important in computer science. These
exercises are supported by a library of instructor provided materials that make
learning fun.
MOTIVATION
While we are teaching programming, it is nice to let the students program with
things that will teach them some simple ideas from courses that they will
encounter later in the curriculum. Some of these things are complex, but with
appropriate scaffolding, even beginning students can use and extend the tools
appropriately. Students have to program with "something." Often it is just
integers and floats at the beginning. It could be things more exciting to them
and which teach them on a variety of levels simultaneously.
APPLICABILITY
The pattern can be used in several courses and at several levels. It can be used
very early in programming courses and in teaching upper level courses as well.
CONTRAINDICATIONS
This requires a fairly long lead time and a lot of effort on the part of
instructors, creating and finding materials. Don't try to use this pattern
without commitment of time and resources.
STRUCTURE
Students are given a library of classes that can be used to implement some
complex functionality. These are the building blocks. They then use them to
build some artifact. Instead of programming with integers and arrays, they
program instead with logic gates, for example.
CONSEQUENCES
This pattern allows students to actively work with larger programs than they can
develop completely themselves. If the tools are chosen correctly, they can also
gain breadth of understanding of the entire field. If the class hierarchy is
well built it also serves as a good model for students building their own
classes and hierarchies later, though the intent is not to teach OOP
specifically.
ISSUES TO CONSIDER
The instructor distributes a class library that implements the basics of some
functionality. The students may either use this unchanged or extend it and use
the extended version to build some project. Care must be taken that the
hierarchy is soundly built, demonstrating excellent techniques, and excellent
structure.
CULTURAL DEPENDENCIES
None.
RESOURCES NEEDED
Fairly rich hierarchies of classes implementing the tools. This is labor
intensive, but resources can easily be shared.
EXAMPLE INSTANCES OF THIS PATTERN
A set of classes that implement logic gates and circuits. Gates can be connected together to form circuits.
An assembly language simulator that lets students get familiar with goto/register programming without all the details of a real machine.
An extension to the above that shows some of the problems with concurrency. A set of classes that let students experiment easily with readers/writers conflicts, for example.
A simple game with complete information that plays against the user but learns from its mistakes.
A simple spreadsheet like program. The program can store "programs" in cells using the simple assembly language of earlier "toys".
A set of classes implementing a simple relational database that can be queried with a simple language.
Decker & Hirchfield's Analytical Engine was a good use of this pattern.
RELATED PATTERN
None
Contributed by:
Joseph Bergin
Pace University
One Pace Plaza
New York, NY 10038 USA
berginf@pace.edu
INTENT
To let the students build a tool kit in early courses for use in later courses.
If well thought out and guided, it can be a wonderful guide to reusable
software. Students become apprentices in the same sense as young people once
served as apprentices in medieval guilds. There they spent their early years
building tools they would need if they were to achieve master status in the
guild.
IDEA
Students build things in early courses that will actually be used later in the
same course and in later courses as well.
MOTIVATION
Students in later programming courses make use of knowledge from earlier
courses, but in the past made little use of the actual programs built there.
Having a personal tool kit of reusable software components can be a wonderful
help in a difficult project. Building the tool kit stresses different, but
important, skills.
APPLICABILITY
The pattern is used most heavily in the early programming courses, especially
the data structures course. However, it can be added to as well as used in
later courses such as database, AI, operating systems, compilers, and the like.
CONTRAINDICATIONS
Not for use in theoretical or "concept" courses.
STRUCTURE
Student exercises have multiple parts. One part of each exercise is to build a
general tool that might be useful in other projects and to take some effort in
its proper formulation for reuse. The design for reuse must be explicit and
must be discussed by the students and commented on by the instructor. Groups of
students can combine individual designs of the tools, discuss the relative
merits of each and then build a common implementation that improves each of the
individual designs.
CONSEQUENCES
Students gain skill in the early courses building reusable components. To the
extent that they fail, the lessons are reinforced in the later courses when they
need to rebuild parts of the tool kit for use in the projects of those course.
Languages supporting reusability need to be used. Most of these languages are
either object-oriented or functional. Scheme, C++, Eiffel, Java, Ada are good
choices. There are a few others such as Modula 3, Beta, Oberon, CLOS, and
Standard ML. Languages supporting genericity (templates) are especially useful.
ISSUES TO CONSIDER
Instructors can provide some tools (data structures and algorithms) in the form
of class hierarchies or other libraries. Students complement this collection.
Time should be spent by students and instructor evaluating student built tools
for correctness, of course, but also for the potential for reusability.
Instructors in later courses must be aware that students have these personal
tool kits and should use exercises and projects that exploit the tool kits and
permit their extension.
CULTURAL DEPENDENCIES
Coordination with later courses is an important element of this pattern.
RESOURCES NEEDED
Thought needs to be given in the design of the early courses as to what tools
are broadly useful, but especially which tools will necessarily be useful in
later courses. Thought should also be given to platform independence of the
tools. The instructor needs a plan and must be able to provide implementations
of those tools that the students will need, but will not build themselves. For
example, the instructor can give a singly linked list and have students build a
doubly linked list. Both would be included in the toolkit.
EXAMPLE INSTANCES OF THIS PATTERN
Kernighan & Plaugher's Software Tools books were a good use of this pattern. This book should probably be read by anyone who wants to implement this pattern. It shows how a high degree of reusability can be achieved with extremely simple tools.
Many data structures, with only slight modification, could be taken as early examples of this pattern.
RELATED PATTERN
Fixer Upper can be used by the instructor to provide partially flawed tools for
the students to comment on and repair.
Contributed by:
Joseph Bergin
Pace University
One Pace Plaza
New York, NY 10038 USA
berginf@pace.edu
INTENT
To give students some early experience in examining a large artifact, beyond
their ability to produce, with the intent of showing them the complexity of the
field they are about to study.
IDEA
Students are given a large artifact to examine early in the course. They can
see what it is that they are supposed to be about in that course and what kinds
of things they will be expected to master.
MOTIVATION
Teaching is often incremental, with topics introduced one after the other.
Students need to see the big picture too as well as the detail. Early on, they
can produce only simple artifacts, but they can examine, if only in a
superficial way, a complex artifact. Seeing the big picture can give them
motivation for the study of the parts as they have an idea of how they might be
used.
APPLICABILITY
This has very wide applicability to almost every domain. It is especially
useful in teaching topics with a lot of parts that must fit together in certain
ways. Teaching programming is one example. Teaching design methodology is
another.
CONTRAINDICATIONS
None.
STRUCTURE
Students are given an artifact at the very beginning of a course that has about
the complexity of the thing you would like them to be able to produce at its
end. Time is spent examining the parts and their interactions. Time can be
spent on trade-offs inherent in the design or not, but the notion of design
tradeoffs should be mentioned at least. The artifact should include most of the
elements that are the proper study for that course. It is good if the artifact
have some subtle points. If questions arise initially on these points they may
be deferred, but it may mean you have better students than you think. The
artifact can be returned to throughout the course and the subtle points revealed
and discussed.
CONSEQUENCES
Students get to see a target for their study. They also have a model on which
they can base their own work.
ISSUES TO CONSIDER
The artifact must be prepared ahead of time. Student projects from prior years
are a good source, though they may need to be modified somewhat to emphasize
points the instructor believes most important. If these are large, a good way
to transmit them to students is via the Internet, especially the Web. This way
other educators can use them also.
CULTURAL DEPENDENCIES
None.
RESOURCES NEEDED
Good solutions to larger projects.
EXAMPLE INSTANCES OF THIS PATTERN
A large Object-Oriented program with a few classes interacting in an interesting way is a good choice in a first programming course using an object-oriented language. A complete design with many documents can be used in a systems design course. A complex database design with entity relationship charts and tables can be used in a database design course.
Some compiler course instructors give the students a complete compiler for one language and then ask them to provided a compiler for another over the course of the term.
RELATED PATTERNS
Spiral Some things can only be taught when tightly coupled to other things so Spiral can help here. This can also be the beginning of the first spiral.
Fixer Upper. If the artifact is flawed it becomes a Fixer Upper.
Early Bird. Complexity and integration of parts is one of the big ideas that Early Bird is trying to get across.
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:
[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
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.
MOTIVATION
Students often have a difficult time understanding software
concepts
which are introduced in a classroom lecture format. This is because the
lecture-lab pedagogy utilizes a "this is what will happen when you do
this" approach which can be too abstract to provide a foundation for
learning software. The LDLL pedagogy offers an alternative approach.
It begins with an introductory step-by-step lab, follows with a
discussion and an explanation of what the students did, and then
reenforces the concepts with a more advanced lab.
APPLICABILITY
Use the Lab-Discussion-Lecture-Lab pattern to introduce a software
tool and/or concepts in a programming language.
STRUCTURE
Lab:
Students complete a step-by-step lab, prepared by the
instructor to introduce the software concepts. This lab must
have detailed written instructions and include questions
which encourage students to record and analyze what they
see on the screen as they proceed through the exercise.
Discussion:
After the lab is completed by each student, the
instructor
leads a student-centered discussion of the following:
- the concepts which were unfamiliar to the students
as they completed the exercise
- any problems the students encountered (in order to
quality control the exercise for future use)
Lecture:
Instructor lectures on the new concepts which were
introduced in the lab, with continuous references to the
experiences the students had while doing the lab.
Lab:
Students complete a more complex lab exercise
which
reenforces and examines each student's comprehension of
the new concepts.
CONSEQUENCES
The LDLL pattern:
- allows students an active involvement in their learning by
introducing them to new concepts as they are using the software
- encourages students to record, and to reflect upon, what
happened
when they were involved in their learning
- enables instructors to give more concrete, less abstract,
lectures
- requires additional work on the part of the instructor to
prepare the
detailed instructions in the first lab
- may take longer than a lecture-lab pedagogy; however, the
increased
level of student comprehension seems to decrease the necessity for
extensive follow-up and review periods
IMPLEMENTATION
Issues to consider:
- Lab exercises can be short (covering one or two concepts) or
lengthy
(covering many concepts). Short lab exercises can be completed
during a designated lab period; for more lengthy labs, it is
recommended that they be assigned and completed outside regular
class hours.
- Since students will be exposed to the new concepts for the
first time
during the first lab, this lab should be written in a detailed, step-by-step
manner and include references to documentation and/or textbook pages
where clarification may be obtained.
- The questions which appear throughout the first lab exercise
should
allow the students to analyze what they enter and what they see on the
screen. These questions will then serve to stimulate and lead the
discussion session.
- Instructors will find that the lecture session, since it is
given after the
lab and discussion sessions, will require a much shorter period of time
than lectures given in a lecture-lab format.
- The follow-up lab should require analytical skills and test
the
student's understanding of the concepts. Unlike the first lab, it should
be evaluated by the instructor.
RELATED PATTERN
(none so far)
EXAMPLE INSTANCES OF THIS PATTERN
This pattern has been used to teach:
- The Smalltalk environment
- Smalltalk programming concepts
- C programming concepts
- BASIC programming concepts
- Fortran programming concepts
Pedagogical Pattern #9
Lecture-Activity-Student Presentation-Discussion (LASD) Pattern
(Version 1.0)
Helen Sharp
The Open University
Computing Department
Milton Keynes MK7 6AA
United Kingdom
h.c.sharp@open.ac.uk
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.
* 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.
INTENT
To expose students to the fundamental principles of good object-oriented design.
MOTIVATION
There are certain fundamental principles on which good object oriented systems are based. Experienced programmers are familiar with these principles and have found them to be necessary ingredients in the design of robust and reusable systems. Design Patterns Demonstrate how these principles can be implemented to solve specific kinds of problems, and therefore provide a rich context in which to teach these principles.
APPLICABILITY
This Pedagogical pattern can be used in any non-beginner type object-oriented course, to teach the fundamental principles of object-oriented design, or to demonstrate how these principles might be implemented in a specific programming language.
STRUCTURE
1. Select a Design Pattern that implements the Principle.
Determine the design principle that is to be focused upon, and select a design pattern that
clearly and concisely demonstrates how this principle might be implemented within a
specific context.
2. Discuss the Design Principle
Use a short discussion or lecture to explain the design principle in terms of its purpose and
the expected outcome of applying it.
3. Present the Design Pattern
Demonstrate how the design principle has been implemented within this pattern in the
following steps:
a) Select one of the following methods to introduce the design pattern:
A formal presentation using class and state diagrams.
The Concrete to Abstract Pedagogical Pattern.
The Incremental Role Playing Pedagogical Pattern.
b) Focus on the section of the design pattern that implements the principle. Observe how classes and objects collaborate to solve the problem.
c) Give an actual example, in which the design pattern has been implemented.
4. Work on a problem.
Introduce a simple design problem that can be solved using this particular design pattern.
Divide the students into small groups, and have each group design a solution to the
problem that utilizes the technique or pattern being taught, and uses the specified design
pattern. The required components could include class diagrams, class interfaces,
implementation code or any combination of these items that provides the optimum
practice for the selected topic.
5. Present Solutions
As many groups as possible should be given the opportunity to display their solutions.
One possibility is to assign each available blackboard to a group and have the groups
simultaneously display their results on the board. Each group can then be given a few
minutes to present key points from their solutions.
6. Discuss Solutions
There should be an open class discussion of the solutions that have been displayed. Each
group should not only present their solution, but discuss how the underlying principles
have been implemented, and the expected advantages of such implementation.
7. Individual Practice
The instructor can set a simple homework assignment that requires the students to
individually design a solution to a given problem by focusing on the technique or principle
being taught.
CONSEQUENCES
1. Provides students with the opportunity to collaborate with others to solve a problem, thereby fostering confidence in individuals, and encouraging listening skills.
2. Exposes students to the skill of applying a known solution to a given problem, instead of "reinventing the wheel".
3. Introduces fundamental Object Oriented principles, and provides students with the opportunity to design a simple system in which these principles have been considered.
IMPLEMENTATION
1. A Design Pattern must be selected that clearly illustrates the Object Oriented Principle that is to be taught without complicating the issue by being too complicated.
2. The examples used to illustrate the design pattern must be ones that can be easily understood by the class, and the group exercises that are set must be based upon problem domains with which the majority of students are familiar.
3. Group dynamics should be discussed with the class before the group exercises take place, so that each individual is able to fully participate in the process.
4. If this method is used on more than one occasion, the groups should be altered so that different people have the opportunity to work together.
EXAMPLE INSTANCES OF THIS PATTERN
Teaching principles of Object Oriented Design such as:
Favor Object Composition over Class Inheritance
Program to an interface and not an implementation
Strive for loosely coupled classes
Teaching Techniques of Object Oriented Programming such as:
Polymorphism
Methods of communication between different types of objects.
Intent
To introduce a design concept behind a complex framework or toolbox that
students will be required to use, so that as the individual components
are
presented, the students can understand how they fit into the bigger
picture.
Motivation
When students learn to use a framework such as MFC, they become
confused by the seemingly endless number of classes and functions.
Design
Patterns that are identified within the framework can be used to create
a
frame of reference for the actual classes and member functions that the
student must become familiar with.
Some topics are best taught by placing students in a situation in which they "discover" for themselves how something works. If that approach were used to teach a framework, then the students would start working with the framework, and as various classes were used, and function calls made, the student would begin to piece together the entire concept. For some students, this process can become very confusing as they fail to build an adequate internal visualization of how all of the pieces fit together. This pedagogical pattern addresses this issue by attempting to provide students with a broad picture into which they can reference the individual components.
Applicability
This pattern can be used when teaching a course such as Visual C++ in
which the student needs to become familiar with MFC, or a Small Talk
course in which the student needs to become familiar with MVC concepts.
Structure
1. Mine Patterns from the framework
The instructor must identify design patterns that are used in the
framework, and determine if any pattern might be useful for
teaching
a specific topic.
2. Explain the Concept
Use the Design Pattern that has been identified as a context in
which
to teach a concept. (For example: the Document/View paradigm in
MFC). Explain the concept behind such a set of classes. Use
charts,
diagrams and other visual aids to explain the concept. The
students
should become familiar with all of the classes involved, and the
types
of function calls each type of object might need to make. This
level
is for understanding concept only!
3. Describe the Actual Implementation Within the framework
Explain the actual class heirarchy and familiarize the students
with
the implementation of the pattern within the framework. The
students should be introduced to real classes and member functions,
so that they understand how the design pattern has been implemented
in the specific framework they are working with. This material can
be covered by a combination of a short lecture followed by a
demonstration of a simple application.
4. Hands On Practice
A lab assignment should be set in which each student is required to
develop a simple application using the features of the framework
that
have just been discussed.
Consequences
1. Exposure to a concept that can be applied to solve many problems,
instead of merely learning the implementation of one framework.
2. Reinforcement of the learning process as the material is presented in two different formats, first as a concept, and secondly as an implementation.
Implementation
1. The instructor must be able to adequately recognize useful design
patterns within an application.
2. As students learn in a variety of styles, this method is best implemented by a combination of lecture, visual aids, demonstration of actual code, and hands on practice.
Example Instances of This Pattern
Teaching MFC (Visual C++)
Teaching MVC (Small Talk)
GOAL:
To help explain object design principles by means of a consistent set of analogies from audio system design to object-oriented design.
AUDIENCE:
This resource is intended especially for students without any programming experience. However, it has also proven useful for more experienced students as well.
PRE-REQUISITES:
None. This idea specifically relates to students who have little or no programming experience.
MOTIVATION:
Students learning programming for the first time have difficulty in learning design because they lack experience with the effects of good or bad program design. To address this lack of experience, we propose harnessing experience from another domain. The domain we suggest is audio systems, meaning CD players, tape-recorders, speakers, headphones, and so on. Most students have experience with these systems, and are able to understand the implications of various designs. We establish analogies from principles of audio system design to principles of OOD, and then recall them when discussing specific object designs.
APPLICABILITY:
The basic idea of analogies is to help explaining an unfamiliar subject domain in terms of a familiar sample domain. This is a strong approach where the students are indeed familiar with the sample domain, and where the two domains do in fact correspond sufficiently well for explanations in the sample domain to provide illumination in the subject domain.
This firstly means that the audio analogies do require that students be familiar with audio components. This is very common, mostly because listening to music is a popular cultural activity, and so audio components are commonplace. Moreover, the analogy works with audio components from the viewpoint of a user of the components, and not detailed knowledge of audio technology is required. However, there may be students who are not sufficiently familiar with audio components, and for these students the analogy will not be helpful.
The correspondence between the audio component domain and object-oriented programming is strong enough to be useful, but like any analogy it is not perfect. The analogy works well for classes, objects, interfaces, encapsulation, and composition. It also works, though not as smoothly, for inheritance and polymorphism. The analogy begins to break down with regard to parameters and customisation, although useful points can still be made. There are difficulties in making sensible correspondences regarding the system flow: the object-oriented domain is typically seen as control-flow oriented, and the audio-system domain seems more suited to a data-flow orientation.
STRUCTURE:
The analogy is really a quite general idea, rather than a specific item. Moreover, it has no concrete aspect: there are no software components. There could be a set of model diagrams or transparency masters, but none are provided currently. The only current artifact is the paper "Explaining Issues in Software Reusability" cited below, which discusses the analogy in detail. Some of the key elements of the analogy are as follows:
Objects: Object identification concerns understanding the nature of an entity with an interface and behaviour. Entities in the audio component domain are easy to understand as they can usually be shown to physically separate, have an understood interface, and a known behaviour.
Classes: In discussing audio objects, different classes of objects can also be easily identified because of mass production of particular components, and interchangeability of kinds of components on the basis of behaviour. Moreover, this can then lead to a discuss of taxonomy, and what interchangeability really might mean.
Interfaces: The interfaces of audio components can either be human interfaces or inter-component interfaces. The human interface, switches, dials, and so on, can be used to explain the nature of an interface, where control of behaviour is facilitated in a limited way. More importantly, the inter-component interfaces can then be introduced in a similar way, describing plugs and matching sockets, tabs and tab-detectors, and so on, and explaining how these also facilitate control of behaviour in a limited way.
Encapsulation: The human interface of audio components allows an easy explanation of encapsulation, as audio components are usually physically encapsulated, except for the provided interface. It can be shown how this allows component integrity to be maintained, and implementation to be modified without modification of the interface or other components. This argument can then also be made for inter-component interfaces.
Composition: While audio components are typically encapsulated, they can physically be opened, voiding the assurances of encapsulation. However, this does allow the internal implementation to be understood, which typically consists of other components, such as transformers, processor chips and so on. The point can be made that such inner components can be used in various different audio components, and that a particular audio component is an encapsulated composition of a set of connected inner components.
Inheritance: The range of audio components can be detailed taxonomically, which might provide a first approach to explaining inheritance. But the real advantage of inheritance in practical programming concerns good understanding of the principles of component interfaces. Inter-component interfaces allow components to be connected in a useful but safe way, typically by the shape of plugs and sockets representing deeper internal dependencies. However, in some cases a new plug can conform to the shape of an existing plug, yet provide different behaviour, a stereo headphone plug conforming to the shape of a monaural headphone plug, for example. In this way, interface conformance leads to greater utility for the context component, such as a tuner, which can be listened to in stereo or monaural sound. Interface conformance is the essence of inheritance as subtyping, which is the real advantage of inheritance.
CONSEQUENCES:
Use of this approach makes it easier to explain object design principles to students who have no experience with program design, or the consequences of good and bad program design. They usually do have experience in using audio components, and can understand the consequences of good and bad design in that domain. The audio component design domain corresponds sufficiently well to the object oriented design domain that the students are then able to better appreciate issues in program design because of the analogy.
IMPLEMENTATION:
The analogy is useful when explaining several detail principles of object oriented design, and useful both in explaining the design principles in the abstract, when they are being introduced as a general concept, and also when discussing specific design issues.
When introducing a design principle in the abstract, the audio component domain can provide a concrete example with understandable implications, at a time too early for the students to really appreciate examples relating to program design. In this way the analogy helps introduce general principles by means of a specific example, at a time that would otherwise make a specific example problematic.
When later discussing a specific design issue, the students might still have insufficient experience to understand the consequences of various design decisions. Such students, quite reasonably, can be unhappy or unwilling to simply trust authority to dictate that certain designs are good or bad, and unable to determine the correct conclusion by themselves. The audio analogy has the benefit of providing concrete examples with understandable implications backed by student experience, rather than relying on acceptance of authority or understanding of principle. For example, to help a student understand why a particular design is poor, a similar design can be sketched out in the audio component domain, where the student will better see how the poor design leads to undesirable results.
RELATED RESOURCES:
The author does not know of any resources that are especially related to this idea. However, anyone knowing of material with a similar approach is invited to contact the author, who will be pleased to investigate and possibly provide references here.
EXAMPLE INSTANCES:
A favourite example of the utility of the analogy concerns a perennial student design decision. Every year, students design many classes with methods that must make some decision and report the result. Every year, some students print out the result, rather than returning it. Every year, these students resist the idea that returning a result is superior design, because in the instance they are considering, printing out the result is exactly what they want. However, we have had success in asking if they would consider purchasing a cassette player that came only with permanently attached headphones, or permanently attached speakers, or a permanently attached cassette! We make the point that indeed in some circumstances these might, surprisingly, indeed be justifiable. However, they must consider the consequences of design in light of reasoning on such a basis, considering future reusability as a key way of making design decisions.
INTENT
To make students apply their [new] knowledge of basic computer terms
and to reason about benefits and trade-offs in specific products.
MOTIVATION
Students need to advance from memorizing terms to applying
technical jargon. Students also need and appreciate the skills and
knowledge necessary to understand a computer ad. Students also
need to realize that they must determine the objectives and constraints
associated with a particular purchase; there is no 'best' computer for
all situations.
APPLICABILITY
This is an exercise for an early course in computing information systems,
including a computer literacy course.
STRUCTURE
Students get into groups and compare computer ads. Each group selects
the best ad for a particular purpose. Representatives from groups
with a common purpose come to the board and present their
choices. The class votes on the best.
CONSEQUENCES
Students see the actual application of concepts and terminology.
Hopefully, students acquire some skepticism about product advertising
and maybe even product development. Students practice some subtle reasoning.
This exercise also serves to de-center the classroom, with the teacher
not being the only authority. Students may volunteer special
knowledge.
IMPLEMENTATION
Students are directed to bring in an ad for a personal computer.
They are encouraged to bring in an ad with terms that they do not understand.
In class, groups are formed. The first task is to look at
all the ads and see if they understand every term.
The teacher circulates and answers questions. It is not a disaster
and may even be beneficial if the teacher does not know something
and just guesses. It may be appropriate to offer extra credit to
anyone who can bring in an explanation of a particular
phrase for the next class.
The second task is for the groups to identify the customer. Possible
choices are student, family, small business, frequent business traveler,
and large company buying multiple machines. Groups identify the best
choice. Representatives from similar groups then come to the board.
They write the brand name/company for their product. They will start to
write down a list of features, but they need to be stopped. The class
is asked to say what is the most important single attribute. This can be
a discussion that the teacher can direct more or less forcefully. The
significant attributes are identified and the representatives write them down. The representatives may be allowed to argue their case.
The class votes.
EXAMPLE INSTANCES OF THIS PATTERN
The pattern can be used for personal computers or auxiliary equipment
such as monitors, printers, modems, scanners, digital cameras, etc.
RESOURCES NEEDED
Students access newspapers, magazines, and the Web.
INTENT
To engage students in the process of making connections between
technical terms.
MOTIVATION
Students often view the set of technical vocabulary terms located at the end
of a chapter as unconnected. By participating in the construction of a
concept map, they are more
likely to appreciate relationships. Students have relatively small and
overlapping
responsibility in this activity and so failure on the part of some students
is not fatal to the
whole exercise.
APPLICABILITY
This pattern can be used in many courses at different levels. However,
it was designed for
a core course in Computer Information Systems required for all
undergraduates and taken
mainly by first year students. It has some of the advantages of a
seminar without relying
on each student to produce.
STRUCTURE
Students are assigned individual terms from the selected chapter. The
assignment is to
bring in a definition or description in your own words of "your term" and
then find two
or three terms that relate to it. Define or describe them and the
relationship. The
relationship can be "similar thing", "opposite", "uses", "attribute", etc.
(Students familiar
with object oriented analysis and/or entity-relationship modeling can be
expected to be
precise, but the exercise has value with beginning students.) In class,
the teacher starts off
with an appropriate starting term and asks if anyone was assigned that
term initially or
used that term in a relationship. The teacher writes the terms
and draws connecting lines
on the board.
CONSEQUENCES
Students must think about their terms. They will hear other definitions.
They can be
prompted for more subtle distinctions. They see different relationships.
The teacher can
contribute to the exposition at the point where students are thinking about
the subject.
Students also are required to speak in front of the class, which is an
effort for many, but
the talk is short and focused.
IMPLEMENTATION
An efficient way to implement this pattern is to use e-mail to send the
terms, giving the
same terms to two or three students. In the core course, we collect
e-mail addresses early
in the term. The term can be put in the subject line of the e-mail and
the body of the note
can be identical for all messages. Students are told to check their
mail on a particular day.
In class, students need to be prompted to contribute even if their
terms are already noted.
EXAMPLE INSTANCES OF THIS PATTERN
The exercise works well with any jargon-laden topic. Good topical areas
in the core
course are Storage and Communications.
RESOURCES NEEDED
An e-mail facility and for the class session a large blackboard or white
board.
INTENT
To help students understand what is required to express a procedure,
the complexities of
concurrent versus sequential processing, and, specifically, to provide an
introduction to
sorting.
MOTIVATION
Students, especially beginning students, have little sense of what a
procedure or algorithm
is. They do not appreciate that each step needs to be specified.
Students also tend to
believe that there is only one way to do something. Concurrent operations
are especially
complex and this can serve as an introduction (and just an
introduction).
APPLICABILITY
This pattern can be done as a general introduction in an introductory
computing class or
later in programming or data structures classes when the students have
more background.
In the latter case, everything would be more rigorous. The sorting of
playing cards can be
replaced by the sorting of something else, such as a class list
or a set of numbers.
STRUCTURE
Students are put into groups. For card sorting, seven or eight works
well. Students are
told to determine a fast way to put shuffled cards in order, making
use of the fact that
there are multiple processors, that is, people with minds, eyes, and
fingers, to do the work.
Groups then present their methods.
CONSEQUENCES
Students must accept the fact that the teacher is asking them to be
more specific than is
their general pattern of thinking. The fact that the specificity is a
real thing becomes
apparent when they realize that there are different ways to
accomplish the same task.
IMPLEMENTATION
The teacher distributes decks of cards and asks the students to shuffle
them. The cards
are described as props only. The teacher generally needs to emphasize
that I do not
need these decks of cards put in order. What I do need is for you to
articulate a
procedure that works effectively.
EXAMPLE INSTANCES OF THIS PATTERN
RESOURCES NEEDED
Decks of cards or other sets of objects to be sorted.
RELATED PATTERNS
This is related to a common classroom programming pattern of having
the students act out
an algorithm.
INTENT
To work with another faculty member to offer a course.
MOTIVATION
A particular topical area may be too broad for one person to handle.
Time requirements
may be too much. This can be a way to explore a new field.
APPLICABILITY One prime generic class of application for this pattern is the use of technology, specifically multimedia, Web research, or Web production in a discipline such as English literature and composition or education or marketing. Another generic class is when one teacher handles the lecture/discussion for a subject and another handles the lab.
STRUCTURE
The patterns that I am familiar with have well-defined roles for each
teacher. This relates
to the key attribute of team teaching: the division of labor. A related
issue is are both
teachers in the room at the same time? In the application of
technology to subject matter
variant, I, the technology teacher and my "content" colleague are both in
the computer
classroom. For the education classes, there is no other venue. For the
English and
marketing courses, the class also uses a regular classroom for the
"regular" instruction and
I am often absent. For the lecture teacher/lab teacher pattern, we
may visit each other but
are not a constant presence. In all these cases, it is important that
the teachers and the
students understand the roles and yet also understand that it is one
course, with the
teachers conferring with each other regularly.
CONSEQUENCES
Team teaching does what is called "de-center" the classroom. The students
seem to take
over more responsibility for the learning when they see teachers learning
from each other.
Students also observe teachers (adults) grappling with issues and
being truly involved in
the subject matter. If there are problems with students, it is
wonderful to have someone to
talk with about the problems.
With multimedia, the two teachers (and the rest of the class) constitute
a real audience for
the student work. In the application of multimedia or any technologies
to a subject area, it
is quite beneficial to show deference to the subject matter teacher.
This reinforces the
message that "content" is more important the technical glitz.
IMPLEMENTATION
For this topic, I will address the prosaic issue of compensation! See
examples below. For
the Beowulf course, I receive 1 credit for my load and my colleague 3.
Note that she does
give a full lecture to the class and has the major responsibility for grading. The other
courses were/will be split evenly.
EXAMPLE INSTANCES OF THIS PATTERN
At Pace University, Dr. Martha Driver and I team-teach a course
giving 3 core literature
credits and one credit cs/is elective called: Beowulf to Lear:
Text, Image and Hypertext.
Our web page is http://csis.pace.edu/grendel
Dr. Sandra Flank and I team teach a summer intensive 1-week course Introduction to
Multimedia for the Classroom.
I am taking over the technologist role and working with Dr. Karen
Berger on Strategic
Web Marketing.
NAME
Assigning and grading (short) team projects (duration for one class session to 2-3 weeks)
INTENT
Team work is now recognized as something that should and can be part of the school
experience since team work will be commonplace in most students’ careers. Team work
In addition, team work can deepen the learning of subject matter because the projects can
be more substantial. This may be especially significant in object-oriented design work
though I suspect it applies to many disciplines as well.
MOTIVATION
Two related issues that emerge often with teamwork are how to assign the teams and how
to give grades. In my classes, students tend to stick with people they know, which, for the
most part, would be people exactly like themselves in terms of gender, age, ethnic
background. I feel it valuable to mix the students up. I also seek to have mixed teams
with respect to skills, both ‘level’ and type.
My approach to the team projects is to give the project one grade and that would apply to
all team members. To me, this most resembles the real-world model. It may be true that
students contribute differently, but that also is the real-world.
(Note: I have heard about what seem to be wonderful approaches for long term projects
when there is a project to ‘fire’ a member.)
APPLICABILITY
These approaches apply to projects given for 1 or 2 week time periods, or even a project
that consumes a single class time.
recently because I forgot the dice, was to have someone flip a coin and produce a
numbeunting off--this certainly separates groups sitting together or a very non-random
approach in which I strive for balance across several attributes: my assessment of their
standing in class (this is usually reduced to my taking the best students and the worst
students and doling them out one to a group), gender, ethnic origin, age (again, I
categorize students as being college age and older and make sure these are mixed).
In longer projects, I may ask the teams to designate roles for each person. This would
include giving a presentation in class. In shorter projects, I tell the teams to divide up the
tasks any way that works for them, but that everyone must understand everything. I roll
dice to determine who speaks for the class presentation on presentation day. In order for
anyone to do this, the students generally spend time preparing props and charts.
Everyone gets the same grade!
CONSEQUENCES
Students take responsibility for the inter-personal issues and project management issues.
Students learn from each other. There is also the phenomenon that individual students
may demonstrate unexpected talents.
IMPLEMENTATION
The class work sessions require me to do the group assignments on the spot so counting
off or names out of a hat or using their ID numbers or e-mail numbers are best. For the
non-random, "balancing" situation, I work on the assignments before class.
I use rubrics for projects.
Throwing dice to determine who presents is something students enjoy. An alternative
tactic, which I used recently because I forgot the dice, was to have someone flip a coin
and produce a number in binary. This was valuable as a review of binary numbers.
EXAMPLE INSTANCES OF THIS PATTERN
Group project to produce Web pages as part of introductory computer information
systems class; group programming project; group data base design project; etc.
RELATED PATTERNS
Anything to do with team projects?
INTENT
To provide motivation for attention by the students and immediate feedback
on learning objects to the instructor by having the students perform
engineering exercises by sitting in groups of three (possible one set of two
due to class count).
MOTIVATION
Instructors often have a difficult time knowing the degree of task
competency during the presentation of complex engineering processes like the
creation of object oriented diagrams. The ILE pedagogy provides an approach
for the instructor to present the method and process for each task within an
object oriented methodology and then to test the students^Ň understanding
before continuing to the next task. Keeps the class from moving on without
all of the class understanding the material. Useful for teaching processes
that rely on the correctness of understanding of the previous tasks.
APPLICABILITY
Use the In-Line Exercises pattern to adjust the level of material being
presented to the level of understanding demonstrated by the students.
STRUCTURE
Task is presented:
Instructor presents the methods and processes required by the students to
perform a task.
In-Line Exercises:
The students, team size of three, perform the task sitting in the same
position that they were during the instructor's presentation.
Alternatively,
the method and process can be contained in the course materials that are
distributed to the students along with a blank worksheet that contains part
of the graphics required for the model.
Review of Exercise:
The exercise is then worked with the class on an overhead transparency.
Alternatively, an individual or team can be asked to write their answer on
the transparency.
Course adjustment:
Instructor can either return to the task to present it again with another
exercise or go onto the next task with an increased understanding of how
well the class is understanding their presentation.
Lab:
Students perform the task immediately with feedback. For adult learners
immediate feedback is key to their understanding and confidence.
CONSEQUENCES
The ILE pattern:
- allows students to know if they are understanding the material being
presented and to develop confidence in their abilities;
- encourages students to ask questions based on problems that they have in
performing the task or additional question that arise from form/style,
correctness, or completeness;
- allows the instructor to find-tune the level of material being presented
to the capability of the students.
IMPLEMENTATION
Issues to consider:
- the instructor needs to be capable of performing the tasks and able to
perform a rapid review of the models as the students prepare them. The
exercise can be from work performed on an actual project or from another
credible reference, the project or references solution can be presented and
contrasted to the work performed by the students;
- the students will ask questions based on problems that they have working
the exercise. A useful technique is to lead a discussion of how the students
worked the exercise: what lessons-learned did they gain; how can they make
it easier for themselves to work this task the next time.;
- keep the in-line exercises simple. A set of simple exercises has been used
with the discussion of the one where the instructor observed the most
difficulty.
RELATED PATTERN
(none so far)
EXAMPLE INSTANCES OF THIS PATTERN
This pattern has been used to teach (examples available from Raytheon
E-Systems Garland classes):
- Systems Engineering Using Object Concepts
- Requirements with Verification and Validation processes
INTENT
To emphasis the relationship between models within an object oriented
engineering process by creating an opportunity for students to present the
UML diagrams that they develop within the context of the other diagrams.
MOTIVATION
Students are often taught each diagram without being taught how the diagrams
relate to each other while in practice there is a high degree of correlation
between the diagrams. The MT pedagogy provides an approach the emphasizes
the transformations. Students are encouraged to make changes to models that
they have previously developed to show that they are gaining an increased
understanding of the system being designed.
APPLICABILITY
Use the Model Transformations pattern while teaching a process that contains
a series of diagrams that contain information that relate to each other
within a larger context.
STRUCTURE
Origin of the design is presented:
Customer operational concepts document, requirements lists, or customer
needs assessment.
First transformation information is extracted:
Operation contexts should be extracted, if engineering is to begin with Use
Case engineering.
First UML model is developed:
Use Case diagrams are prepared from the transformation information and
verified back to the original source of the desired system.
Next set of transformation information is extracted:
From the Use Cases, system responsibilities can be extracted in preparation
for finding classes.
Next model is presented:
Class diagrams are prepared from the responsibilities transformation
information. Interaction diagrams have proven useful in related use case
engineering and class modeling engineering efforts.
Repeats the "next" steps while working through all of the UML models.
CONSEQUENCES
The MT pattern:
- the degree of consistency between the drawings is increased due to
understanding the information that ties the diagrams together;
- students are more aware of the impact of changes, they know if the change
relates to transformational information and what other diagrams need to be
updated;
- provides the instructor with the opportunity to discuss the management of
change.
IMPLEMENTATION
Issues to consider:
- student teams can prepare their UML drawings on easel paper-sheets, a
series of easels can be lined up across the front of the class room,
students present each diagram by discussion the transformation information
first. This allows the students to discuss changes to previous diagrams as
they continue design from diagram to diagram while learning more about the
system and capturing the knowledge as it is realized.
RELATED PATTERN
(none so far)
EXAMPLE INSTANCES OF THIS PATTERN
This pattern has been used to teach:
- Software Systems Engineering Object-Oriented Analysis and Design
- Transitions for UML modeling
MOTIVATION:
When encountering frequently used classes, the student is usually
presented with the list of attributes and member functions, challenged to
code the class and then write a program using the class. This does not
develop object "thinking". The Responsibility Driven Class Development
pattern teaches introductory object design concepts and reinforces object
thinking.
APPLICABILITY:
Use this to develop classes used in introductory courses - strings, stacks,
queues, lists, linked lists, graphs.
STRUCTURE:
1. Responsibilities: using the CRC card approach, determine what the class should know, what are its reponsibilities and its collaborators.
2. Create a UML diagram for the class and document member functions.
3. Identify and discuss "small" use cases to refine the class and develop
member function parameters.
Does the class know enough, have enough responsibility to ... ? For
example, in developing a list class, can we search the list for an item? can
we add an item to the list? What data does the class need to receive to
carry out the responsibility?
4. Implement the Class
Use analogy, visual, and abstract representations to motivate code
development. Test the class with a test harness.
5. Use the Class on a significant use case.
CONSEQUENCES:
In the early courses where this approach is used, the students pick up the
language and elementary object design techniques. With repetition, the
students get comfortable with CRC cards, responsibility driven design,
simple UML diagrams and the idea of use cases.
IMPLEMENTATION:
It's important to avoid over directing the initial CRC discussions. For
the pattern to work, the instructor must avoid comments like "we must be
able to push data on a stack - right?". Let the students come up with their
ideas. If you then move to a text book (pre-designed) class, you can
discuss how the responsibilities identified by the students are (or are not)
met by the class in the text.
The students can work together to develop a test driver that exercises all of the classes responsibilities. This gives everyone a way to verify the implementation of the class before using it in a larger project.
EXAMPLE INSTANCES:
This pattern has been used effectively in data structures and
algorithms
courses to teach: Strings, Stacks, Queues, Lists, Search Trees, Graphs,
Hashing
MOTIVATION:
When being introduced to a new concept, students too often concentrate
on the details, without looking at the high-level aspects of the
problem. Also, for a student to properly appreciate a concept, a
problem example need to be posed that is excellent for analysis and
architectural design, but may be too large for detailed design and
implementation in the classroom environment.
APPLICABILITY:
This pattern can be used to introduce any major computing concept,
although it of course works better in some areas than in others.
STRUCTURE:
Concept: Introduce the new idea, using real-world analogies as much as possible. As the students questions related to their real-world experiences in this area. ("How do you..." "What if...")
Glossary: Giving the students a glossary of new terms related to a subject area is important. Not all of those terms need to be addressed immediately. Having each term, where possible, compared to something they have experienced before can be especially useful.
Problem: The students should then be posed a real-world problem that uses this concept.
Analyze: The students should then, in small teams, analyze the problem statement ("customer requirements"). The instructor can act as a mentor and/or customer during analysis.
Discuss: The students then share their analysis with the class, and the positive and negative aspects of these analyses are discussed.
(Note: The Problem-Analyze-Discuss segment can be done in several increments where appropriate.)
Design: The instructor can then discuss how a specification results from this analysis can be converted into an architectural design. This step can also be done interactively with discussion, and in increments, as was shown for the Problem-Analyze-Discuss segment. This step should NOT ordinarily follow with further steps in the life cycle.
CONSEQUENCES:
1. Allows the students to understand a new idea without worrying about
the details.
2. Allows the students to appreciate the concept using a real-world
problem example that is excellent for analysis and architectural design,
but too large for detailed design and implementation within the
constraints of the course.
3. Allows the students to work in small groups to solve a problem,
which helps them to quickly understand a new concept.
IMPLEMENTATION:
A little more preparation time is generally needed, despite the fact
that there is more student participation than normal. A glossary
probably takes up most of this time. Finding a good real-world problem
is also essential.
EXAMPLE INSTANCES OF THIS PATTERN:
CoG-PADD has been successfully used to teach the object-oriented
paradigm, task-based concurrency, and the logic-based paradigm. The
object-oriented instance is described in [1], although not precisely in
terms of CoG-PADD. In this case, the "problem-analyze-discuss" segment
is performed in increments. The creation of that instance, which led to
the development of the CoG-PADD pattern, was inspired by a technique
Alistair Cockburn uses to teach the object paradigm [2], which would
best be described as an instance of a "concept-design-discuss" (where
the "design-discuss" phase is done in several increments) pattern, if
such a pattern exists.
REFERENCES:
[1] Bagert, Donald J. Object-oriented design resources for CS2. OOPSLA
'97 Research Workshop on Resources for Early Object Design Education,
Atlanta GA, 5 October 1997.
(http://www.bk.psu.edu/faculty/mercer/design/Bagert.htm)
[2] Cockburn, Alistair. Teaching OO design is teaching how to assess
the design's future. OOPSLA '96 Research Workshop on Teaching and
Learning Object Design in the First Academic Year, San Jose CA, 6
October 1996.
(http://www.bk.psu.edu/faculty/mercer/design/16Alistar_Cockburn.htm)
MOTIVATION:
I strongly believe that the first 1-4 weeks (typically 8 1+-hour lectures
with 3-4 lab sessions) are crucial in setting up students'
mind sets with regard to OO. If objects are not introduced and emphasized
as the artifacts whose manipulation is at the center
of programming, the remainder of the course, and subsequent courses tend
to suffer from the continued and repeated struggle
to eliminate bad (e.g., non-OO) habits and misconceptions.
AUDIENCE:
The pedagogical pattern is meant to govern the very first weeks of
teaching a a "Computer Science I" course. It is assumed
that students are complete novices to the object-oriented paradign, and
possibly computer programming in general.
STRUCTURE:
More discussion and insight is needed on what we could call "OO teaching"
(how about OOT?). OO teaching should put
objects and related concepts like aggregration, inheritance, and
polymorphism in the foreground. That entails that these topic
are introduced from the very beginning, instead of being banned to the
final chapter (or even appendix!) of introductory OO
textbooks. It also entails that the introduction of classes and objects --
when included in earlier chapters-- not be given in an
overly gentle and timid fashion, only to be followed by chapters on
functions, conditionals and iteration, before finally hitting the
student over the head with a linked list (frequently, topics of
inheritance and polymorphism are omitted entirely). First we go
too slow, then too fast. No wonder, many students do not manage to get on
track. I believe that more conducive to learning
OO would be the presentation of topics in roughly this order:
1.Objects, Classes, object state
2.Aggregation
3.Object behavior, member functions
4.Inheritance
5.Polymorphism
6.Conditionals
7.Iteration
8......
The first exposure to functions will be in form of member functions ("what the object does"). Many students tend to have difficulties with functions initially; maybe the purpose of a member function will seem more intuitive and facilitate the understanding of the benefits of functions in general. Conditionals and iteration will be motivated as constructs that allow the specification of more richer object behavior. In other words: let's not practise conditionals and iteration in the body of a "big main", but in the body of a member functions; e.g., if-then-else comes in handy if a member function is to ensure that no illegal/ nonsensical object states be defined; iteration will allow the specification of object behavior that is repetitive.
If students are instructed from the very start to associate most (or, initally all) program behavior with small-bodied member functions belonging to objects, there will be less of the typical cramming of "everything the programs is to do" into a "big main".
CONSEQUENCES:
Students that will emerge with significantly greater familiarity, comfort
and skill in object-oriented analysis (OOA), design
(OOD) and programming (OOP).
The key to this style of teaching, will lie in its wholistic and practically "zero-alternative" approach to learning about the full spectrum of OO concepts in the earliest stages of learning to design and implement OO programs. Students will have embraced a sizable problem solving and programming paradigm by having been given the "big picture" (the OO paradigm) on a small scale (through small, intuitive examples).
Students will model data as objects because that's how problem-specific data were represented from the start. Students will express program behavior through member functions associated with objects because that's how objects were brought to life from the beginning. Students will use inheritance because that's how one could avoid restating the already established. And lastly, students will understand polymophism as a way of making adjustments to inherited behavior that has become inappropriate in the more specialized context.
IMPLEMENTATION:
The suggested approach to OO-teaching (I suggest: OOTch) essentially
consists of not much more than a reordering of your
typical Computer Science I and II textbook topics. Any instructor
experienced with OO will be able to adopt this approach.
The here presented suggestions address the first 1-4 weeks of OO teaching
only. Beyond those weeks, a course may follow
any one of numerous good textbooks on OO programming, with the added
advantage that most likely more interesting
examples than those presented in books can be dealt with. For example, no
longer will sorting have to be taught as sorting an
array of integers (how boring!), but sorting may be applied to an array of
student_records or houses_for_sale, or just
about any artifact whose object-oriented representation at this point
comes natural to the students. What will be required of the
instructor adopting this approach is the consistent and repeated
reinforcement of the OO paradigm as a way of approaching
the problem. For every new program, the same kinds of questions should be
discussed in class:
What are the objects in this problem?
What are the important parts and properties of the objects?
Are these primitive parts (representable as int, char, ..) or are
these parts objects in their own right?
What do these objects do? What behavior should they meaningfully
exhibit?
Have we seen/dealt with/programmed objects before that are very
similar? Do the new objects differ from those in that
they have additional parts or properties?
If we let our new objects adopt the parts and behaviors from already
defined objects, are the adopted ("inherited")
behaviors still appropiate for the new objects, or should some
behaviors be modified?
Answering those questions each and every time will have students practise looking at a problem with "OO eyes". It will naturally have them work with aggregation, inheritance and polymorphism. As the resource included below hopefully demonstrates, it is quite easy to come up with simple and intuitive examples.
The first four weeks of teaching Computer Science I in the suggested object-centered fashion are sketched out below. Several concrete object classes, specified in C++, are included as sample resources. Two things should be noted here. (1) You may view the use of C++ as a notation/shorthand to allow a less verbose presentation of the ideas. (2) You may view the bits of C++ code as parts of concrete class/lab exercises that demonstrate how in informal examination of objects in some problem domain is being translated into the syntactic constructs of a concrete programming language (Contrary to some, I believe that learning about syntax (which is generally agreed on as being the "easy part") does not have to be in the way of teaching design; the successful compiling and running of a program can be seen as valuable verification of one's design.)
Week-1: The class informally discusses the notion of an "object" as we know it from our daily experience with the physical world. The instructor may bring along some artifacts and let students describe them. Discover that many objects are composites, and are readily described in terms of their parts and properties. Looking ahead to subsequent lectures, students may also be instructed to discuss the kinds of behaviors (= things to do) that different kinds of objects are expected to exhibit. The discussion should be held at an informal level that allows all students to contribute.
Next discuss the notion of a "program" as a set of instructions that will have the computer manipulate data (= pieces of information = objects) to arrive at solutions to a given problem. A program needs to be informed of the kinds of objects (parts and properties) to manipulate. Since computers are not capable of understanding natural languages, objects are described to the program in a socalled programming language, C++ being one of many options. The previously informally discussed description of a type of object is now written out using programming language syntax. At this point, students are also taught that the programing language knows about several basic types of objects, from which all composite objects are to be built. These basic types are int, float, char etc.
An example for a resource for Week-1 defines a "house for sale" object that lists the number of bedrooms, square feet, asking price, address etc. as parts and properties. The corresponding class definition is kept simple in that all parts and properties are basic types of objects, and declared public (a minimal explanation of public should suffice at this point).
Week-2: The House_for_object is reexamined, and the discovery of other parts of the house is encouraged. Students will be led to suggest parts that are not representable as basic objects but are objects in their own right. For example, the house for sale can come with a garage (described in terms of how many cars it fits), and appliances (described as being of a brand name, and either powered with electricity or gas). Let students experience how new objects Garage and Appliances are defined in analogy to House_for_sale.
Effectively, the notion of aggregation has been introduced. In addition, it is fairly easy to lead over to the basics of encapsulation. At this stage, suffice it to say that parts and properties defining an object are precious and vulnerable to corruption (how about somebody indicating a negative number of bedrooms, or filling in some fantasy brandname?). Labeling parts and properties as protected will safekeep the state of an object.
Once the defining parts of an object have been rendered invulnerable, they have also been rendered inaccessible. Lead students to understanding that a carefully crafted interface will allow us to access and manipulate the parts and properties of an objects in a fashion that is intentionally restrictive; it allows only what is needed and meaningful, and disallows acts of corruption. The interface will initially be minimal and consist of exactly two member functions (= "behaviors") per part or property: one function that allows the assignment of values to the part, and one function that allows the access/retrieval of the part's value.
Week-3: Week-2 will have motivated the notion of a function. While other types of functions exist, no harm is done in letting students believe that a function is something that an object "does". In fact, the lack of any alternative to OO will counteract the development of non-OO programming habits from the start (... there will be no "big main()", and their won't be function calles other than calls to member functions; that in turn means that all data has been conceptualized and designed as objects).
Staying with the design of a House_for_sale object, students will find the interface too restrictive. Encourage the discovery of other meaningful member functions. For example, suggest that the house be able to avertise itself. A new member function House_for_sale::advertise() could print out a brief statement such as "This beautiful new home has 4 bedrooms and ...". Notice that beyond the syntax for class definitions and member functions, only standard input and output have to be taught which leads to inevitably very simple member functions. Next encourage students to discuss in more discriminate terms what kinds of houses may be up for sale. The notion of a "fixer-upper" may come up. Let students discuss the notion of a "fixer upper" compared to the earlier notion of a house for sale. Are there differences? Let students discover, that all parts and properties describing a house for sale, also apply to a fixer-upper, yet there is additional information that is typically provided along with the latter (e.g., the year it's been built, and whether it has lead paint and asbestos). Conclude Week-3 by having students write a C++ specification of Fixer-upper in analogy to the most recent definition of class House_for-sale.
Week-4: Discuss with students how it felt to be writing the specification for a class Fixer_upper. Did they find it repetitive at all? Would they want to repeat this experience for other types of houses on sale? Wouldn't it be nice, if you could tell the program that Fixer_upper is just like House_for_sale with some additional features? Having thus triggered their curiosity (and fed their budding discontent with the repetive exercise), they will be receptive to the notion of inheritance. A Fixer_upper can indeed by defined as a specialized subclass of House_for_sale, and not much additional syntax to express this relationship is needed. Demonstrate to students how easily the subclassing is expressed, and stress the convenience of having to add C++ specifications for only the additional features of the subclass.
Now examine the subclass Fixer_upper more carefully. It inherits all parts, properties and member functions from its superclass House_for_sale which is a good thing, except ... Point out that Fixer_upper also inherits member functions House_for_sale::advertise(), and that the function effectively advertises the object as "This beautiful new home ...". . This is clearly inappropriate for objects in the fixer-upper subclass. A fixer-upper should still be able to advertise itself, and the inheritance of this capability makes perfect sense. However, the messsage of the advertisement should be a different one. After students have appreciated the discrepancy, they will be receptive to the possiblity of redefining the message. Teach students that the inherited member functions advertise can be {\em overwritten} as part of defining Fixer_upper. The function retains the old (and entirely appropriate) name, but its body is changed to, say, "This affordable fixer-upper with great potential ...". And thus, at the week of Week-4, we have covered basic forms of polymorphism. The rest is reinforcement... Other standard topics of programming (conditionals, iteration, arrays, pointers, etc.) can now be taught in the usual sequence, but with the added motivation of allowing the expression of more sophisticated object behavior.
MOTIVATION
It is always hard to begin learning - it often occurs, that students
spend a lot of time to be familiar with a certain material
(concept/method/procedure/tool). If the material is large and difficult,
it is very hard to catch something concrete, from which one can go step
by step.
It is very important for the students to see very small and complete patterns first, then immediately to do the exercise by their own by little modification of the pattern. It is much easier learning this way. Every student wants to see a pattern for every topics of the material. The basic patterns must be built on each other; they must be evident; they must be easy to follow and modify all over the material.
APPLICABILITY
This pedagogical pattern is well known and applicable everywhere, though
it is not widely used. It is very good in teaching program development,
but especially applicable in teaching OO concepts and OO software
development. Though OO thinking is very natural, the implementation of
OO concepts turned out to be quite hard to understand.
STRUCTURE
The topics of the material are built on each other. Every topic consists
of the following parts:
* The teacher shows a simple but complete pattern. The pattern goes into
the details exactly to the depth that the problem is wholly
understandable and traceable from the beginning to the end.
* Teacher categorizes the elements of the pattern into a small number of
category.
* Students modify the pattern
* Students get a problem which they can solve modeled on the given
pattern.
CONSEQUENCES
* The pattern is applicable in teaching many things.
* Students have success solving small problems quickly.
* Students can understand the related concepts easily.
EXAMPLE INSTANCE OF THE PATTERN
I give a sample application structure of teaching OO design and
programming. The pattern has four object stereotypes (categories):
window, control, container and entity. The main OO concepts are
discussed during the course. The topics and the related patterns and
concepts are the following:
* Topic: Object and class. Pattern: it has one window class, and one instance of that class, a window. Related concepts: classification, encapsulation, information hiding, messaging.
* Topic: OO design: The pattern has two or three windows of the previously discussed or developed window class. The pattern has a control object which controls the windows. Related concepts: associations, control object, collaboration diagram, class diagram.
* Topic: Inheritance: The pattern has the previously discussed window class and a specialized window class. The pattern also has a control object which now controls the special windows. Related concepts: specialization, inheritance, polymorphism, late binding, visibility.
* Topic: Container class. Implementing the 1:N association: The pattern has now a control object and several special or not special window objects. Related concepts: container, iterator, polymorphism, type casting.
* Topic: Entity objects. Pattern: similar to the previous pattern. In the container there are also entities. Windows are the interfaces to the entities. Related concepts: entity object, interface object.
It is very important to show and develop all details. For every problem the student must see the following things: Simple collaboration diagram; Class diagram; Class descriptions; Code
Consequences of this pattern instance:
* In spite of the pattern's simplicity, there are infinite variations of
problem specifications to find out.
* The source code can be made in 3GL or 4GL languages, in pure or hybrid
object-oriented languages. It is better to use pure OO language though
to force the student to use OO technique.
* Using a framework, the control, interface and container classes are
ready and reusable.
RESOURCES NEEDED
None
RELATED PATTERNS
None so far
MOTIVATION
Concepts related to requirements analysis, validation and verification,
system
analysis, design, teamwork to mention a few, that are tackled in a
Software
Engineering or Systems Analysis course are too abstract for students to
conceive their worth without hands on paractice. The latter is typically
addressed by having students exercise some of these concepts through
assigned
problems or lab projects. However restricting students to lab environments
deprive them of exercisig the issues in their rightful habitation namely
the
work place. The motivation for this pattern is to take the students well
beyond
the class room and labexperience by giving them the opportunity to get
involved
in real world situations.
APPLICABILITY
It can be used in any software engineering or object-oriented analysis and
design course.
STRUCTURE
Students are organized into teams of 2-3 members.
1. Each team chooses a project from any domain of interest. Projects may
target
banking, insurance, a doctor's practice, a pharmacy, game etc.
2. Each team is responsible for finding a person from that domain who is
willing to act as the domain expert. It is preferable to choose an expert
who
is interested in reaching a complete software product because such an
expert
would be willing to invest the time necessary to to reach sound user
requirements, to provide feed back in intermediate stages as well as to
determine the validity of the final product.
3. Each team conducts a series of interviews with their domain expert (at
the
experts work place) to determine requirements definition that could
include
functional and non functional requirements.
4. Each team submits these requirements to the instructor for evaluation.
Evaluation would be made to ensure that these requirements are sufficient
to
start the next stage.
5. Each team rewrites the requirements guided by the instructor's
evaluation
and after re-consultation with the domain expert.
6. Each team starts with the analysis phase using an OO methodology.
7. Outputs from the analysis phase are submitted to the instructor for
evaluation. The evaluation would be made to ensure that:
* The concepts were applied correctly.
* The outputs are consistent with user requirements.
* The outputs are at an appropriate level of abstraction.
* The outputs do not make commitments to a specific implementation.
8. Each team amends outputs of the analysis phase guided by the
evaluation.
9. Each team starts on the design phase.
10. Outputs from the design phase are also submitted to the instructor for
evaluation. The evaluation would be made to ensure that outputs of the
analysis
phase were unfolded consistently to the right level of detail.
11. Each team implements the design.
12. Each team demonstrates the produced software for the domain expert for
validation purposes.
13. Each team modifies the implementation based on step 12.
14. Finally each team supports a report that includes the outputs of each
phase. In addition the report includes:
* A user manual for the developed product
* A description of the test cases that were used to verify the produced
software.
* A self assessment component that discusses the validity of the
implementation
against user requirements as well as the team's experience.
* A letter from the domain expert assessing the product from her/his own
perspective
Setting due dates and having students abide by these is essential. Grading and assessment of such a project would be based on the submitted report and on the validity of the outputs of each phase of the development. Students in the same team may get different grades.
CONSEQUENCES
* Students practice the concepts and methods taught to problems in real
work
environments. This helps to enforce the viability of concepts and methods
taught and to introduce students to industrial work experience.
* By involving a domain interest, students are motivated to finish the
target
project with a matching interest to learn the material introduced during
lecture hours.
* Demonstrating the finished project for a domain expert enforces issues
of
validation vs. verification.
* Working in teams of 2-3 helps to elucidate issues related to team and
team
work and gives a fair chance to reach a complete product.
* Abiding by due dates in producing the ouputs of different phases and a
complete report on the developmet process is essential to reinforce issues
related to project planning, scheduling etc.
* Producing a complete report from A to Z emphasizes issues related to
project
documentation and project maintainance.
* Grading students within a team independently mimics to a large extent
staff
evaluation where staff members are evaluated, promoted etc. independently
of
their colleagues.
IMPLEMENTATION
1. The project must be of the right size and appropriately focused to
finish
in a one semester course.
2. The availability of a domain expert who is willing to offer the time
is
essential.
3. The contents of the lectures must be suitably timed to proceed ahead
of the
different phases of the project.
4. The assesment of the instructor of the outputs of different phases is
made
to focus the students on the target task and to ensure that the concepts
have
been assimilated and applied correctly.
EXAMPLE INSTANCES OF THIS PATTERN
This pattern has been used repeatedly in an OO Software Engineering
course.
RELATED PATTERNS
This pattern is related in theme to the Preparation, Industrial
Presentation
and Roundtable (PIPL) Pattern. (#15)
MOTIVATION
Students in an OO teaching framework are repeatedly preached on the
advantage
of reuse. One approach to reinforce this advantage beyond the use/reuse of
library classes is to actually have students reuse existing designs and
implementation.
APPLICABILITY
It can be used in a OO Software Engineering Course, OOAD course or in
other
advanced OO course that emphasizes reuse of various forms inparticular
design
reuse. It requires availability of a pool (library) of project reports and
corresponding implementations that students can refer to for reuse.
STRUCTURE
1. Apply steps 1 through 8 of the LINK pattern.
2. Based on the assessment of the submitted design, the instructor acting
by
and large as the library manager refers the designers (students) to
related
designs from the existing project library for reuse purposes. Typically
reuse
is possible because applications fall into few general frameworks:
Database
oriented, GUI, games etc.
3. From this stage onward student follow the remaining steps of the LINK
pattern referring as they do so to the existing library inorder to achieve
as
much reuse as possible in each stage of the cycle of their project
development.
4. The report that is submitted must include a section that describes the
kind
and amount of reuse that has been done.
CONSEQUENCES
Applying this pattern allows the student to practice reuse beyond the
use/reuse
of existing library classes. For a course that relies on design patterns,
it
helps the student to appreciate the usefulness and the viability of these
patterns.
IMPLEMENTATION
* A library of projects (including reports and implementations) must be
implemented that will create the pool to which students can refer for
reuse.
Alternatively the LINK pattern could be applied in teaching an OOAD or an
OOSE
course to generate this pool.
* The instructor must familiarize themselves with the existing pool of
projects
in order to be able to play the role of the library manager.
* The implementation requirements of the LINK pattern apply to this
pattern as
well.
EXAMPLE INSTANCES OF THIS PATTERN
This pattern has evolved as a result of applying the LINK pattern
repeatedly in
teaching an OO Software Engineering course.
RELATED PATTERNS
The LINK pattern. This pattern also relates in theme to the Tool Box
pattern
(#36). The Reuse pattern goes beyond code reuse to design reuse.