Resources for Next
Generation Introductory CS Courses
Report of the ITiCSE’'99 Working
Resources for the Next Generation
CS 1 Course
Pace University, USA
Viera K. Proulx
Richard Stockton College of NJ,
Ramapo College of NJ,
Alma College, USA
Rose-Hulman Institute of Technology,
Montana State University,
The ongoing purpose of this working group is to collect,
evaluate, and foster the development of resources that might be used in next
generation introductory CS courses. Such courses will integrate elements of
object-oriented programming and design, program design patterns, concurrency,
and event-driven programming. The product of the working group is a web
repository that provides resources that might be used in such a course. The
site will include sample syllabi, pedagogical patterns, programming and design
patterns, course modules, projects, tools and techniques.
The URL for the web site is:
The time seems ripe for reconceptualizing the introductory
courses in computer science. Over the past few years the first course has
become, in many universities, an introduction to programming and little else.
More positively, there has been a shift away from procedural programming in the
direction of object-oriented programming, though a number of institutions
continue to do a good job with Scheme and the functional paradigm. This working
group was brought together in the belief that the teaching of introductory
courses in computer science needs to be improved and that Java, in particular,
gives us opportunities for advancing on a number of fronts to improve both the
content and the pedagogy of the introductory courses.
We believe that for the next several years, the
object-oriented paradigm will continue to advance and will be the predominant
development methodology for almost all software. The implication of this seems
clear: the paradigm must be at the core of computer science education.
However, the object paradigm is not a simple extension of the
procedural paradigm, as the metaphor of independent interacting objects and the
nature of late binding changes the focus of design. The implication is that the
programmer must adopt a particular mental model of computation to be successful
with the object paradigm. This further implies that the pedagogy of objects is
different from that of other programming paradigms.
The members of this working group are committed to finding
ways to develop this new pedagogy and to promote its use in the CS education
community. However, rather than just talk about the difference and exhort our
colleagues to learn new ways of teaching, we believe that techniques and
resources for accommodating this new pedagogy must be demonstrated. We also feel
that many of the tools and examples used by educators who are teaching other
paradigms are not entirely appropriate for teaching object technology and so
there is a need for new course resources that use this new methodology
effectively. This working group begins to fill this need.
2 COURSE DESIGN CHOICES
The working group members are not going to try to predict all
features of new introductory courses, beyond the choice of the object-oriented
paradigm. Java was chosen for its features and not because of any belief that
its use is necessary in such a course. Indeed, Java merely sets a focus for our
work, some of which was begun in other languages, notably C++. Indeed, one of
the modules developed here introduces assembly language.
The intent is to provide resources that might be used by
instructors in courses designed according to their own standards. We do believe
that some topics that have not traditionally been taught are becoming more
important to software development generally, and so we have focussed on these
areas. Among these topics are concurrency, event-driven programming, graphical
interface programming, and programming and design patterns.
The course also needs to be more than a course in programming
techniques. Design may be introduced in a variety of ways, through the use of
standard OO diagramming techniques and design patterns. Breadth may also be
brought into the course by judicious choice of the projects on which students
work. These are intended to show the student the range of possibilities of
The choices that an instructor must consider in defining the nature of object-oriented
introductory computer science courses include the following.
Objects-First vs. Procedural-First
It is generally agreed in the computing community that programming
using the object-oriented model requires a different approach and way of thinking
than traditional procedural programming. The object model requires a distribution
of computation among objects in which the sender of any given message may
not know the type of the receiver or the implementation of the message action.
In concurrent situations, it will not even be clear at what time certain messages
It has been found that practitioners who were trained on the
top-down procedural paradigm cannot easily make the paradigm shift to the
object model. This means that the question of how to teach students entering
the discipline is quite important.
Based on the belief that it will be harder for students to learn if we
force them into a paradigm shift, the objects-first approach exposes students
to objects from the very beginning. Conversely, in the procedural-first
approach students are gently led up to objects to avoid a perceived cognitive
Linear vs. Spiral Coverage
When using linear coverage, the instructor completes coverage of one topic
before moving on to the next. When using spiral coverage, the instructor
visits each topic several times over the course of the introductory sequence,
incrementally covering the material on each pass.
Closed vs. Open Laboratories
In closed labs, contact time is dedicated to having students solve problems
under the instructor's supervision. In contrast, students solve problems
in open labs on their own time without direct supervision.
Breadth-First vs. Depth-First Coverage
In breadth-first coverage, selected topics from various computer science
fields are carefully introduced through examples and exercises. Alternatively,
the first course may focus on programming only.
Sequential vs. Concurrent Paradigm
Students can be taught traditional single-threaded execution or the course
can contain elements of multi-threaded, concurrent programming.
Using Toolkits vs. Base-Language
Instructors may choose to use toolkits and development libraries that support
the pedagogical process (e.g. I/O objects) or choose to work exclusively
with the standard base language and libraries.
Instructors have a range of choices in the form of user interaction used
in their exercises and examples, from text-based, to graphical output, to
Of the choices described here, this is the only language-specific
choice. If Java is chosen, the instructor must decide whether to use applets,
applications, or both.
The pedagogy of object-oriented program design is
fundamentally different from traditional ways of teaching introductory
programming and design. Polymorphism, late binding, and message passing demand a
change in program design techniques. The client/server view of computation is
especially useful. Therefore, the pedagogy is much less bottom-up so that
students deal almost immediately with larger program components (e.g.
It also encourages the assignment of larger student projects
and allows students to work on small parts of very large projects. Students are
introduced early to standard libraries and become comfortable with the idea of
reuse and working in environments in which they have little or no control over
some parts of the project.
The Pedagogical Patterns Project
describes a number of different techniques that can be used in teaching computer
science and especially object-oriented programming and design. The working group
repository will catalog appropriate existing pedagogical patterns and develop
new pedagogical patterns that aid in teaching with objects. Modules included in
the repository will reference the applicable pedagogical patterns.
4 PROGRAMMING AND DESIGN PATTERNS
Programming and design patterns provide a framework for the
presentation, discussion, and refinement of software design and programming
techniques. The design patterns community (http://www.hillside.net/patterns/)
uses patterns as a means of communicating detailed problem-solving techniques
and effective software architecture designs. To some extent, a pattern is an
attempt to discover and codify best practice with respect to a
problem or class of problems. For example, the Model-View-Controller (MVC)
pattern describes a way of organizing objects and classes to decouple data
models from the way that they are displayed on a screen.
Elementary programming patterns are extremely simple design
patterns that can be used by novices in learning programming. See, for example,
the Elementary Patterns home page at:
They provide a way for educators to formalize the motivation,
context, structure, applicability, and consequences of the concepts they teach,
even in the earliest courses. This is a relatively new focus within the
patterns community, so only a few programming patterns have been identified and
documented [Astrachan 1998]. One example is the Selection Patterns [Bergin
1999], which describes variations on selection constructs (if, if-else, switch,
etc.) and characterizes which situations call for which variation.
The working group's web site provides links to existing programming
and design patterns and identifies other useful pattern topics for future development.
The categories of programming and design patterns included are:
- Objects and
- Interacting objects and
- Class definition
- Composite structures and
5 TOOLKITS AND COMPONENTS
Toolkits are collections of components that can be used to
support student programming efforts over the course of many laboratory
assignments. They can make it possible for students to accomplish tasks that
would be difficult to do using just the raw base programming language. Among the
areas that toolkits might support are a standard look and feel for student
assignments; robust and flexible IO; graphics, plots, visualization, and
animation; and concurrency.
Individual components (objects and classes) that may be used
in lectures, demonstrations, or laboratory exercises also form a potentially
valuable pedagogical resource. Although it is straightforward to build what may
be called computer science classes (arrays, lists, trees, graphs),
it is more difficult to invent classes that apply to real world problems and can
be understood by students. It is helpful, therefore, for faculty to have a
source for a variety of such real world components.
We envision toolkits and components, available in source form,
together with appropriate tutorial documents that explain the functionality and
pedagogical purpose of the package. Faculty will then be free to adapt the
materials as desired.
6 COURSE MODULES
A number of course modules have been developed or collected by
our group. They are divided initially into six categories. The primary category
is the Integrated Course Module. Such a module consists of a preliminary
document to be examined by students, an in-class exercise, an outline of a
lecture and an open lab exercise to be completed by students. The preliminary
document may be a design or a program, together with some explanation. It
requires study prior to the introduction of the topic in class. Group study is
preferred to individual study in these modules. The in-class exercise often
consists of a team interaction creating a design of something similar to the
preliminary document. The open lab provides depth in the topic through student
design and programming. Here team projects are especially encouraged. The design
of these modules broadly follows the pedagogical patterns expressed in papers in
the Pedagogical Patterns Project.
Other types of modules currently included in the repository
Stand-alone Project Modules
Each module contains ideas for one substantial stand-alone
Programming Patterns Modules
Each module is a collection of short exercises that allow the
student to practice a particular programming pattern in a variety of situations.
These exercises may or may not be packaged with a discussion of the
Mini-Lectures / Mini-Labs
Each module is a collection of pairs of mini-lectures and
associated mini-labs that explore a topic.
Examples of Classes and Objects
Each module consists of a collection of objects that can be
used as examples of interesting objects for teaching. Some of these may be
accompanied by short handouts for students or simple verbal exercises.
Toolkits and Components
As discussed above, this is a collection of toolkits and
components that supports teaching of the introductory course. The goal is to
provide a stable base upon which students build their programs. For example,
tools may support building GUIs, provide support for safe control of threads, or
support robust filtered input operations.
7 HOW YOU CAN PARTICIPATE
We envision three ways the wider community can participate in
our project. First, individuals are invited to submit resources to the project.
Accepted resources will usually remain on the developer's site but will be indexed,
with links provided from the repository site. The repository site will maintain
an annotation page for each included resource. Providing annotations for existing
resources is the second way that individuals can contribute to the project.
Lastly, comments and suggestions for improvement will always be gratefully accepted.
8 EXISTING RESOURCES
A number of existing resources may be used effectively in the
new introductory courses. Some examples follow; others will be on the Web
Karel J. Robot
The book, Karel++: A Gentle Introduction to the Art of
Object-Oriented Programming, has been updated to Java by Joseph Bergin, with
new material added. The new material covers the transition to object-oriented
programming in general, and concurrency, including CSP style programming.
The BlueJ project of Michael Kölling at Monash University
in Australia provides a very usable design and development environment for
Computer Education Research Group, Monash
Monash University has established a web site for resources for
teaching introductory courses that use Java.
9 RELATED WORK
A number of other projects incorporate ideas and resources
that are directly applicable to this one.
Lynn Andrea Stein at MIT is developing a new first course in
computing that emphasizes concurrency.
The ACM/SIGCSE and the IEEE Computer Society have jointly
undertaken a new project to examine the computing curriculum [Roberts 1999].
Curriculum 2001 intends to produce a new set of curriculum guidelines
appropriate for current practice.
Northeastern Software Project
Resources developed at Northeastern University for teaching
C++ to freshmen are available at
Java materials will be added during the next two
Rose-Hulman's CS 1 laboratories
Rose-Hulman Institute of Technology has developed a collection
of closed laboratories (and associated materials) for teaching freshman an
introduction to computer science using Microsoft Visual C++. The materials are
available at URL: http://www.rose-hulman.edu/Class/cs/cs100.
The working group leaders would like to thank the members for
their hard work. We would all like to thank Dan Joyce for his work in organizing
the ITiCSE working groups and making all of the arrangements that brought us
Astrachan, O. and Wallingford, E. (1998) Loop Patterns.
Rasala, R. (1997) Function Objects, Function Templates, and
Passage by Behavior in C++, ACM SIGCSE’'97 Proceedings,
Roberts, E., LeBlanc, R., Shackelford, R., and Denning, P. Curriculum
2001: Interim Report from the ACM/IEEE-CS Task Force (1999). ACM SIGCSE’'99
, Available: http://www.acm.org
12 FURTHER READING
Bergin, J. (1997) Ten Pedagogical Patterns for Teaching
Bergin, J. (1998) Six Pedagogical Patterns.
Fell, H. J., Proulx, V. K., and Rasala, R. (1998) Scaling: A
Design Pattern in Introductory Computer Science, ACM SIGCSE’'98 Proceedings,
Rasala, R. (1999) IOTools A Model Toolkit for Freshman
Wolz, U., and Koffman, E. (1999) simpleIO: A Java Package for
Novice Interactive and Graphic Programming, Proceedings of the 4th
Annual SIGCSE/SIGCUE ITiCSE’'99 Conference, 139-142.