no 10

43

Recent evolution of the introductory curriculum in computing

A l l e n B. T u c k e r a n d D a v i d K . G a r n i c k

Department of Computer Science, Bowdoin College, Brunswick, ME 04011, USA

Abstract. This paper traces the evolution of the first courses in undergraduate programs over the last twelve years. We ideatify fundamental weaknesses in the present sequence, and propose strengthening the introductory curriculum, using a breadth-first approach that integrates theoretical material.

Keywords: introductory curriculum, discrete mathematics, scheduled laboratories, social and ethical context, programming methodology

Allen B. Tucker is Professor and Chair of the Computer Science Department at Bowdoin College. He is the author of several books and articles in the areas of programming languages, natural language processing, and computer science education. He served on the recent ACM Task Force on the Core of Computing, and was co-chair of the ACM/IEEE CS Joint Curriculum Task Force. Professor Tucker is co- author of the articles "A model curriculum for a liberal arts degree in

computer science" (Gibbs and Tucker, CACM, 1986) and "Computing as a discipline" (Denning et ah, CACM, 1989).

David K. Garnlck is Assistant Profes-

al

sor. of Computer Science and Dana Faculty Fellow at Bowdoin College. His research interests are in the areas of distributed computing, heuristic algorithms and computer science education. He is working together with Pro- fessor Tucker and Professors Robert Cupper and James Bradley on a four- volume series of books and laboratory suites for the introductory curriculum in computer science. His special interests in computer science education in-

volve the integration of writing into the curriculum and the use of the discovery method in the classroom.

Education & Computing 7 (1991) 43-60 Elsevier

Introduct ion

The in t roduc tory courses in comput ing t have

undergone significant evolut ionary changes in the 12 years since C, trricuhon 78 [2] was published. Some of the most recent versions of these courses represent d ramat ic departures from the tradit ional model that had p rogramming as its centerpiece. Trends have developed that would give these

courses a broader discipl inary reach, as well as an improved t rea tment of the discipline 's theoretical

and labora tory science dimensions . If m a n y undergradua te programs no longer fol-

low ACM'S s tandard guidelines for these courses, then what guidelines do they follow? In light of the rapid evolut ion of comput ing as a discipline through the 1980s and in to the 1990s, it is fair to explore the strengths and weakness of various models for in t roduc ing the discipline to potent ia l

majors. This paper explores significant trends in this

search for al ternatives to the t radi t ional in t roductory sequence in comput ing. We also present a new model which is mot ivated in part by the principles set forth in a recent ACM task force report [12], and assess the potent ia l advantages and disadvantages of widely implement ing this

model in undergradua te curricula.

The traditional introductory sequence

In 1978, the ACM Curr icu lum Commit tee on Compute r Science presented Curricuhtm 78: Rec- ommendations for the Undergraduate Program hi Computer Science [2]. Curricuhtm 78 prescribes the na ture and conten t of the in t roductory course sequence, as well as that of the more advanced courses. In 1984, an ACM curr iculum task force revised the r ecommenda t ions for the first two courses in the in t roduc tory sequence, called cs1 and cs2 respecively [19,20]. These revisions served

1 Read as "computer science," "computer science and engineering," "informatics'" or any similar title.

0167-9287/91/$03.50 © 1991 - Elsevier Science Publishers B.V. All rights reserved

44 A.B. Tucker and D.K. Garnick / bttroducto O, curriculum in computing

principally as an elaboration and update of the recommendations in Curricuhmt 78. These course recommendations provide a basis for the introductory sequence as currently taught at a large number of colleges and universities in the tlSA. Thus, we begin by reviewing the nature of these courses and identifying the strengths and weaknesses of this traditional model.

Content and goals

Under Curricuhml 78, the introductory courses, CSl and cs2, were titled "Computer programming 1" and "Computer Programming 2." These titles adequately describe the content of these courses. The 1984 revisions of these two courses did not redefine their purpose, but simply updated them, in order to reflect the advances in block-structured languages and programming methodology; csl and cs2 were retitled, respectively, "Introduction to Programming Methodology" and "Program De- sign and Implementation." z

Thus, cs1:84 is concerned mainly with topics that map directly into syntactic and problem solving aspects of programming in a block-structured language, usually Pascal. The main topics of CSl : 84 can be summarized as follows: • Introduction to computer hardware, software,

editors and other system features. • Programming language syntax: data types, con-

trol structures, procedures, recursion, arrays, strings, records.

• Problem solving strategies: specialization, gen- eralization, divide and conquer, procedural abstraction, top-down design, pseudocode.

• Program coding, debugging, testing and documentation. The homework for this course consists of pro-

gramming exercises, done by students working independently. A weekly scheduled laboratory is suggested, in which students can learn the techni-

2 For clarity and distinction from their predecessors, we shall refer to these revisions of CS1 and CS2 as CS1:84 and CS2: 84, and to their predecessors as CS2 : 78 and CS2: 78. This notational convention will also be used to distinguish later versions of these and related courses as they are identified in later parts of this paper. When we use the terms CS1 and CS2 without qualification, this will intentionally desig- nate the first two courses in the curriculum in a more generic s e n s e .

cal tools that support program editing, debugging and execution.

The course cs2: 84 is a continuation of programming methodology from the first course, with the addition of some data structures and large problem solving techniques. It covers the following topics: • Programming methodology: specification, de-

sign, coding and correctness. • Elementary data structures (lists, stacks, queues,

trees and files) and their implementations (linked and array).

• Searching and sorting algorithms: serial, binary, hashing, bubble sort, quicksort, external file merging.

• Computational complexity (O-notation). • Recursion and its trade-offs with respect to

iteration. • Some optional advanced topics: graph al-

gorithms, formal specification, invariants and verification. The time students put into these courses out-

side of the classroom is primarily spent writing and testing programs. Clearly, the two introductory courses are designed to train students as programmers:

The student completing cs2 will be able to successfully design and implement large programming systems involving multiple modules, using good programming style. 120]

The next two courses in the introductory sequence of Curriculum 78 are cs3:78, Introduction to Computer Systems, and cs4:78, Introduction to Computer Organization. These two courses concentrate on the rudiments of hardware (logic design, data representation and basic processor design) and the software interface to the hardware (assemblers, linkers and loaders). These courses, together with cs1:84 and CS2:84, are designed to give computer science majors "a thorough ground- ing in the study of the implementation of algorithms in programming languages which operate on data structures in the environment of hardware" [21.

The fifth course in the introductory sequence is cs5 : 78, Introduction to File Processing. The course covers sequential and random access files and tree-based structures for organizing data on bulk storage devices. This course is somewhat of an anachronism, not because the techniques covered are unimportant, but because it is questionable to

A.B. Tucker and D.K. Garnick /Introductory curriculum in computing 45

have an entire course on such a narrow topic at this early level in the curriculum. Furthermore, this course's content has become seriously dated by subsequent developments in database and information retrieval systems and technologies.

Curricuhtm 78 contains a number of additional courses beyond these, including the following required courses:

cs6: 78, cs7: 78, cs8: 78,

Operating Systems and Architecture; Data Structures and Algorithms; Programming Languages.

Beyond the required courses are a host of electives that round out the curriculum, including the following:

cs9:78, Computers and Society; cs10:78, Operating Systems and Architecture II; CSl5: 78, Theory of Programming Languages; cs16:78, Automata, Computabil i ty and Formal Languages.

While it is not the purpose of this paper to com- ment on the entire undergraduate curriculum, we list these courses here for two purposes. First, we shall see later that significant material from these courses has found its way into lower-level courses in recent years. Second, we note that the Theory course and the Computers and Society course of Cttrricuhmz 78 appear only as electives, and not among the required courses in the curriculum.

Returning to the first three introductory courses in this sequence, we note that they lean heavily toward training students as programmers. Even cs3:78 is devoted mainly to assembly language programming. 3 It would be unfair to conclude from this that the designers of Curricuhtm 78 naively believed that computer science was synon- ymous with programming. Presumably programming, as the principal tool of the computer scientist, was viewed as the means of entry into the broader range of topics that comprised the discipline. However, two of the six stated objectives of

Curricuhun 78 directly emphasize the importance of programming.

Computer science majors should: 1. be able to write programs in a reasonable amount of time

that work correctly, are well documented, and are readable; 2. be able to determine whether or not they have written a

reasonably efficient and well organized program. [2]

Strengths and weaknesses of the httroductory sequence

The introductory sequence in this traditional curriculum has several strengths. They can be summarized as follows:

Programming expertise Much of the course work in the introductory

sequence is devoted to programming. Class lectures and laboratory work complement each other to give students extended explanations and practical experience in the syntax and use of block- structured p rogramming language constructs. Thus, many students, within a year or two, become whizzes at producing the kinds of programs that typify the weekly assignments in introductory courses.

Data strtlclures

There is full coverage of the basic data structur- ing techniques: arrays, records, lists, stacks, queues, trees and hash tables. Through an introduction to the analysis of algorithms, as recommended in [20], students come to understand trade-offs among competing techniques.

The existence of weaknesses in this model is evi- denced by the large amount of experimentation in the introductory curriculum thht has taken place during the last several years. Recent surveys show that fully half of the undergraduate programs in computing follow models different from these hCM-recommended guidelines.

As practical as the attention to programming is, the weaknesses in the traditional introductory sequence stem from this narrow focus. The principal weaknesses of CSl : 84 and cs2: 84 are:

3 Though these courses were presented as a sample for the introductory sequence, they represented a mapping of the material that was intended to go into any introductory sequence.

Narrow discipline coverage The introductory sequence does not provide an

introduction to the discipline of computing as a

46 A.B. Tucker and D.K. Garnick / httroductory curriculum in computhlg

whole. By the end of the sequence, a typical student will neither know what the subfields in the discipline are, nor have a sense of what computer scientists do. Given that a student's first exposure to computing is a heavy dose of programming, even later courses are likely to be viewed as covering increasingly detailed programming problems. Many of the brightest students are, in fact, bored by this course and are driven toward consideration of majors in other disciplines.

Lack of theory Computing methodologies are not presented in

the context of the principles that underlie the discipline. For example, in cs1:84 and cs2:84 students grapple with the logic of programs, while in CS4:78 they study logic design. Only in the discrete mathematics course, which some students do not take until they are well past the introductory sequence, do students study logic and Boolean algebra in depth. The same problem occurs with the dissociation of combinatorics, complexity and graph theory from the cs2:84 course, where it is used in the study of algorithms and data structures.

Since this elementary mathematical material is relegated to a course of its own, it is usually viewed by students as an arbitrary hurdle that must be cleared so that they can get on with studying computer science. No introductory course in the curriculum model directly relates the principles of logic, combinatorics and graph theory to their many applications in computing.

Lack of scientific methodology in laboratory work Typical course projects require students to code

straightforward programs that illustrate linguistic constructs, system features or applications. Lab assignments are not designed to allow students to discover important principles of computing. Thus, students receive training in program implementation rather than in the process of experimentation, discovery and evaluation which is more typical of advanced work in computing.

Outdated programming methodology Ironically, cs1:84 and cs2:84 are weak in one of

their intended key areas: programming methodology. The traditional model espouses a strict top- down methodology that maps designs on to procedures in a block-structured language. At best, this

methodology is only one of several competing approaches (others being object-oriented and functional); at worst, it is an outdated approach that is only appropriate for programming in the small. Further, typical courses do not devote much time even to this methodology; the most widely used texts for CSl and cs2 devote only 12-25 pages to design methodology [7,8,9,18]. Finally, the teaching of programming methodology in csl and cs2 is limited by strict adherence to traditional block-structured languages, especially Pas- cal; such languages are pedagogically weaker than modular languages, such as Modula-2 and Eiffel, which permit students to develop programs using the most contemporary principles of abstraction and design.

Avoidance of social issues Introductory courses ignore social issues that

the discipline of computing uniquely faces. Among these are intellectual property, privacy and system reliability.

Practical concenls

It is important not to overlook the ways in which the traditional sequence is well-connected to the current academic environment. The most prominent connections are to:

AP e x a m

The high school advanced placement curriculum [5] follows the current ACM recommendations for the courses cs1-84 and CS2:84, as outlined above. The AP exams allow many students to place out of CSl : 84, and the occasional student to place out of cs2:84. Changes in either of these courses will have direct and significant impact on the AP curriculum.

bztennediate and advanced courses Upper-level courses in the major assume a

background commensurate with the existing introductory sequence, and are built upon them as prerequisites. Changes in the introductory courses will affect some of the intermediate courses in the curriculum.

Reliance oll other departments and graduate students

In many programs, mathematics and electrical engineering departments staff some of the courses

A.B. Tucker and D.I~ Garnick / Introductory curriculum in cornputing 47

required for the major in computing, especially CS1:84, Discrete Mathematics and Logic Design. Changes in the computing curriculum will affect how and when such courses will be staffed, and how well their respective subject matter will be covered.

Service courses CSl : 84 is often used as a service course to teach

programming to students in science and engineering departments. If that course were to concentrate less on programming skills, it might no longer meet the needs of other departments.

Faculty e.xpertise Changes in the introductory curriculum may

require some faculty (especially those without graduate training in computing) to seek further training. The uniformity of the sequence from school to school permits faculty from different institutions to share teaching materials and suggestions. Additionally, the uniformity allows graduate students readily to start up courses as they take up faculty positions.

Texls There is a host of available textbooks for the

traditional sequence.

Labs: software, hardware and classrooms Computing labs are configured to serve courses

where students individually and independently code and run programs. Also, the software needs, which consist of one or two compilers and an assembler, are easily met.

For the most part, these connections are a result of the relative stability of the introductory curriculum over the past ten years; they are not an outcome of features intrinsic to the design of the traditional introductory sequence.

Evolution of curricula in the 1980s

As the discipline of computing has evolved, so has the undergraduote curriculum. Many people now consider the modified version of Curriculum 78 that was described in the foregoing section to have become somewhat obsolete as a model curriculum for contemporary programs to follow. A number of important new themes have developed

during the last several years; these are described in this section.

The role of mathematics and theory

The need for more mathematical orientation in the first course in computing has been widely recognized. Ralston [24] draws distinctions between a CSl course that teaches programming skills to first-year students and a CSl course that intro- duces students to the principles that underlie the discipline of computing. The latter uses the programming language as a vehicle for illustration and exploration of the principles, rather than as an end in itself.

Ralston goes on to argue effectively that first- year students need to know and use a considerable amount of mathematics, especially discrete mathematics, as they begin their study of computing. Essential topics in a freshman-level discrete math course, which we will call DM:84, are:

Elementary mathematics (summation, subscripts, specific simple functions--abs, trunc, trig, logs, prime numbers, gcd, floor, ceiling);

General mathematical ideas (functions, sets and operations on sets);

Algebra (matrix algebra, Polish notation, con- gruences);

Summation and limits (elementary summation, O-notation, harmonic numbers);

Numbers and number systems (positional notation, non-decimal bases);

Logic and Boolean algebra (operators and expressions, proof);

Probability (basic concepts of sample spaces and laws of probability);

Combinatorics (permutations, combinations, counting, binomial coefficients);

Graph theory (graphs, trees and their properties); Difference equations and recurrence relations

(solutions, generating functions).

These topics are pervasive in computing, especially in the following parts of the curriculum: - analysis of algorithms; - array (mathematical and statistical program-

ruing) problems; - computational complexity (efficiency); - f u n c t i o n a l programming and procedural ab-

straction;

48 A.B. Tucker and D.K. Garnick / Introductory curriculum in computing

- compilation of arithmetic expressions; machine language models;

- random number generators and their uses; - sorting and searching algorithms; - recursion in problem solving; - program verification; - logic design and computer architecture; - machine level (binary and hexadecimal) number

representation and arithmetic; - operating systems; - networking problems; - compilers.

Because of the fundamental importance of these discrete mathematics topics in the introductory curriculum, Ralston recommends that DM:84, aS described above, be made a prerequisite to cs2. Although the designers of cs2:84 acknowledged this relationship, there is really very little depend- ency shown in current cs2 textbooks upon the topics that appear in this discrete math course. Thus, practically speaking, students do not neces- sarily have any particular level of mathematical maturity at the time they take the cs2 course. This is a serious problem, if we really believe that computing is a scientific discipline. As a rule, the sciences do require and use principles and nota- tions of mathematics throughout their curricula, beginning with their introductory courses. Com- puting should be no different.

The implementation of a more theory-oriented computing major was suggested in the Liberal Arts Model Curriculum [15]. This model is based on the reaffirmation that computing is a scientific discipline (cf [11]), and therefore undergraduate majors ought to be exposed to its experimental and theoretical dimensions, alongside its programming and engineering dimension. Two introductory courses and four core courses comprise the realization of this model:

CS1:86, an introductory course along the same lines as cs1:84. However, this course, following the distinctions pointed out by Ralston, sees the programming language ideally as a vehicle for intro- ducing the student to the discipline of computing - - the emphasis is on algorithms and programming methodology, rather than on language syntax.

CS2: 86, departs significantly from cs2: 84, including a detailed study of data structures and data abstraction, an introduction to the notion of al-

gorithm analysis and O-notation, a consolidation of knowledge of program design from csl (especially emphasizing the design of large problems), and a survey of the discipline of computing.

CS3: 86, Principles of Computer Organization: levels of architecture (logic, microprogramming, machine language, macro assembly, operating system); processors (instructions, memory, registers, addressing, i /o , control); interrupts and multi- tasking; assembly language (macros, assemblers, linkers, loaders).

cs4:86, Algorithms: complexity, searching and sorting; mathematical algorithms (matrices, poly- nomials, algebra); tree and graph traversal; NP complete problems and intractable problems.

cs5:86, Theory of Computation: automata (finite, pushdown, non-deterministic); regular expressions, Context-free grammars; Turing machines, Godel numbering, Church's thesis, universal TM; halting problem, unsolvability, limits of computation.

C~:86, Principles of Programming Languages: language syntax (lexical properties, Br~F, parsing); language processors (compilers, interpreters); language representations (data structures, control structures, binding, the run time environment, formal semantics); language styles (procedural, functional, oop, logic programming, and their uses).

In addition, the Liberal Arts Model requires that two mathematics courses, including IgM: 84, be prerequisite to the core courses cs4:86 and cs5:86. That discrete math course follows along the lines of Ralston's ideas, both in content and in the level of its presentation in the curriculum. The main departure of this model from Curricuhmz 78 is its insistence on a significant amount of theory among the introductory and intermediate-level courses. This follows in .the spirit of Denning's concerns expressed in his educational ruminations [10]. In short, the-principle expressed here is that theory and abstraction ought to precede appfications and technologies in their order of presentation. Since its inception, this particular model has been widely used as a guide for the development of undergraduate major programs.

A.B. Tucker and D.K. Garnick / h~troductory curriculum in computing 49

The influence of these ideas on the evolution of Curricuhm~ 78 was also recently summarized by McCracken [21]. That summary showed how the core elements of Curricuhtm 78, Ralston 's ideas, the Liberal Arts Model Curriculum and other recent developments, have been merged into the configurat ion of undergraduate courses shown in Table 1.

This summary shows us what specific subject matter has migrated downward through the curriculum in the last 10 years, and where it has finally landed. It is clear, for instance, that significantly more theory appears explicitly among the required courses than was the case a decade ago. It is also clear that a significant shift of da ta structures and algorithms material has migrated into the cs2 course. It is finally clear that, in spite of all the curricular movement a round it, the CSl course has retained its basic identity as a pro- grammh~g course throughout the entire decade. These observations can also b e confirmed by an examination of current undergraduate catalogs of various colleges and universities.

Efforts to broaden the introductory curricuhtm

While significant changes are taking place in the entire core curriculum, the focus of this paper will be on the effects o f these changes on the content of the first three or four courses in the cu r r i cu lum-- those listed above as CSl : 89, cs2 : 89,

Discrete Ma themat i c s (DM : 84) , Archi tec ture (CS3 : 89) and Algor i thms (cs4: 89).

hldividual courses

Some undergraduate programs have independently recognized the need for broader-based in- t roductory courses, and have begun to experiment with revising their syllabi accordingly. Below are two textbook examples of such revisions for the CSl course.

The first example [25] incorporates into the CSl course concepts o f machine architecture, artificial intelligence and computabi l i ty , along with traditional topics of searching, sorting and data structures.

Logic with electricity (Boolean algebra, gates, De Morgan ' s laws);

Memory (clocks, shift, registers, decoding); Ari thmetic (counting, addition, multiplication); A n ari thmetic and logic unit (binary adder); Control and p rog ramming (registers, loops); P rogramming and unsolvabili ty (the halting prob-

lem, pcp); Searching and sort ing (analysis of algorithms); Da ta structures (l inked lists, heaps, stacks,

queues); Stacks, subrout ines and recursion; Translat ion (assembly); An algori thmic language;

Table 1 Summary of curriculum evolution: 1978-1989

Freshman CS1 : 89 CS2 : 89

DM : 84

Sophomore CS3 : 89

CS4 : 89

Junior CS5:89

CS6:89

CS7:89

a course composed from CS1 : 84 and ADT's from CS2: 84 a course like CS2: 86, i.e. composed from CS2 : 84 CS2 • 84, CS5 : 78 (file structures) and CS7 • 78 (data structures) Discrete mathematics

Architecture and digital logic, like CS3 : 86, composed from CS3 : 78 (computer systems), CS4 : 78 (computer organization) Data structures and algorithms, like CS4: 86, composed from CS7:78 (data structures and algorithms), CS2" 78 (programming), CS3 : 78 (algorithms) and CS1 : 88 (see below)

Theory, like CS5 : 86, composed from CS6 : 78 (automata, computability, formal languages), with an applied flavor Programming Languages, like CS6 : 86, composed from CS8 • 78 (programming languages), CS5 : 78 (theory of programming languages), and CS1 : 88 (see below) Operating Systems, composed from CS6 : 78 (operating systems and architecture), CS4 : 78 (computer organization), CS5 : 78 (file processing) and CS10 : 78 (operating systems and architecture II)

50 A.B~ Tucker and D.K. Garnick / Introductory curriculum in computing

Practicalities (operating systems, i /o, user interface);

Machine intelligence.

The second example [32,31] argues for a broader introductory course based on the natural hierarchy of levels that are used to describe typical computer systems.

Logic gate level; Microprogramming level; Machine level; Operating system level; Assembly level; High-order language level; Applications level.

This course also uses a simulated computer that allows students to be exposed to the various levels of architecture through hands-on laboratory experiments.

Experimentation has also taken place with the cs2 course, in which the cs2:86 model serves as motivation. There, efforts are made to provide a broader survey of the discipline of computing, along with a responsible introduction to data structures, abstraction and complexity. Examples of texts that address the course in this way are [1,6,28]. In the case of [1], some institution use it for both of their csl and cs2 courses.

The entire c s I - c s2 -c s3 sequence Some programs have experimented with a coor-

dinated revision of all three courses in their introductory curriculum so that they cover the discipline more broadly and abstractly. For example, the following is a summary of the first three courses in Stanford's 1987-88 undergraduate curriculum [26], covering four quarters of coursework (roughly equivalent to three semesters).

namic data structures, selection of data structure for an application.

• Software Engineering: top-down design methodology, pseudocode; correctness through testing; testing strategies; style and documentation; software life cycle; examination of large programs; requirements and specifications.

• Systems: batch programming with file i /o; in- teractive programming; user interface qualities; translation versus execution time; use of an editor; use of a compiler; identify system com- ponents.

• Computer Science: languages (syntax and semantics, syntax diagrams, vocabulary), abstraction (data and procedural, top-down analysis and stepwise refinement, pre- and post-con- ditions), applications (practice programs, applications language such as an editor, relationship to other disciplines).

CS2:87 (called cs 108A, Fundamentals of Computer Science I: one quarter) • Models and abstraction: computer science, des-

ign versus implementation, models and algorithms, propositional logic, predicate logic, circuit design.

• Analysis of algorithms: computability, complexity, verification.

• The underlying machine: architecture, processing and fetch/execute, representation.

• Semantics of programs: procedural (machine and assembly language, high-level languages, imperative model and states), declarative (Pro- log, declarative model), functional (Lisp, functional model).

• Programming environments: translation, inter- action, programming support tools.

• Program design: issues, encapsulation, modulus, ADTS, object-oriented analysis, functional de- composition.

csl:87 (called cs 106, Introduction to Software Engineering: two quarters) • Algorithms: selection and looping, procedures

and functions, recursion, simple algorithms (search, sort, max, average, merge, string).

• Data structures: storage representation of in- tegers, reals, characters; arrays, records, enu- merations; levels of data structure description (abstract, implementation, application); data abstraction and encapsulation, pointers and dy-

cs3:87 (called cs 108B, Fundamentals of Computer Science II: one quarter) • Operating systems: UNIX, commands. • Language concepts: finite state machines, gram-

mars, BNF, automata, regular expressions. • Language implementation: compilers and inter-

preters, parsing and ambiguity, naming, scope, binding, parameter passing, activation records, storage management (heaps and stacks).

• Programming concepts: history, C, ooe (Small-

A.B. Tucker and D.K. Garnick / Introductory curriculum in computing 51

talk), software design, encapsulation and generic packages (Ada), searching and sorting.

• Data models: graphs, trees.

As we can see, the range of topics covered in these three courses is quite a bit broader than that covered by the traditional introductory course sequence in computing. Particularly notable innova- tions are their inclusion of logic, computability, semantics and alternative programming para- digms.

Emerging models for addressing broader goals

The above evolutionary changes have therefore tried to incorporate more theory into the introductory curriculum, to identify a new rfle for laboratories and scientific experimentation, and to provide a broader view of the discipline of computing to introductory-level students.

This need for a broader, discipline-based model for designing introductory courses for the major was reinforced in [12]. There, a definition of the discipline of computing, encompassing the full range of computing subjects, was elaborated in the following way.

Nine major subject areas and three major processes are identified as comprising the entire discipline of computing. These are commonly identified in the 9 × 4 array shown in Table 2.

The processes of theory, abstraction and design are distinguished from each other in such a way that the mathematical, scientific and engineering dimensions of the discipline are made explicit. That is, in each of the subject areas, there is an underlying mathematical foundation (theory), an

experimental, hypothesis-testing scientific activity (abstraction) and an engineering activity (design).

For example, in the area of architecture, its underlying theory comes from Boolean algebra, switching theory and automata theory. Its abstractions are finite state and sequential machine models, array processor models, and so forth. Its design elements include specific computer architectures, such as the traditional yon Neumann machine, and efficient units for machine arithmetic.

The area of programming languages has theoretical foundations in formal languages, Turing machines and the lambda calculus. Its abstractions include classification by style and application area (for example, procedural, functional, logic and object-oriented), abstract implementation models (compilers, interpreters), and auto- matic generation of parsers and compilers. The design of programming languages includes specific languages (for example, FORTRAN, Pascal, C, Eif- fel), compilers, programming environments, parser generators and related tools.

The fact that each o f these nine areas has a distinguishable theory, abstraction and design component helps to clarify the basic unity of the discipline of computing, as well as its place among the traditional scientific and engineering disciplines.

Also shown in Table 2 is a fourth column, entitled "Social context," which recognizes that the discipline has social and ethical dimensions not addressed by the other columns of the matrix. Many argue that the introductory sequence in computing ought to address these dimensions in substantive ways [23].

To illustrate the usefulness of the matrix as a measure of discipline coverage, Table 3 shows the subject areas and processes covered by the tradi-

Table 2 Array of subject areas

Theo ry Abstraction Design Social context

Algorithms & data structures Programming languages Architecture Numerical & symbolic computing Operating systems Software methodology & engineering Database & information retrieval Artificial intelligence & robotics Human-computer communication

52 A.B. Tucker and D.h: Garnick /lntrodttctory curriculum in computhTg

Table 3 Discipline coverage by the present sequence--CS1:84, CS2:84, CS3:78, Discrete Math

Theory Abstraction Design Social context

Algorithms & data structures DM Programming languages DM Architecture DM Numerical & symbolic computing DM Operating systems Software methodology & engineering DM Database & information retrieval Artificial intelligence & robotics Human-compuler communication

cs2 cs2 CSl, 2

cs3 cs3 cs2

cs1, 2 cs1, 2

tional introductory courses discussed in the previous section. It is interesting to note the following characteristics made apparent by the matrix: - the theoretical material (in DM:84) is pedagogi-

cally disconnected from the introductory courses cs1:84, cs2:84 and cs3:78;

- four of the nine subject areas receive no coverage; and

- social issues receive no coverage. The matrix also lends itself as a basis for re-

thinking the introductory curriculum in computing. That is, if the introductory course sequence should indeed introduce students to the broad range of subject matter in the discipline, it is not unreasonable to try to design, say, a three-semester sequence of courses that cover all nine subject areas and four processes in the above definition. Such a model was proposed in Appendix II of [12], excepting coverage of the social dimension. It is summarized as follows:

CS1:88

• Fundamental algorithmic concepts (6 weeks): search, sort, quicksort, correctness, efficiency, procedures and scope, recursion, survey of programming styles.

Labs: write programs, modify programs, compare alternative solutions, convert between recursion and iteration.

• Computer organization (5 weeks): von Neu- mann machine, multiple-register machines, in- p u t / o u t p u t devices, levels of architecture (gate, microprogramming, machine language).

Labs: develop simple assembly language programs, hand-translate a Pascal program to assembly language.

• Mathematical programming (3 weeks): integer and real number representation, well-condi-

tioned and ill-conditioned problems, overview of mathemat ica l problem solving areas, packages, specialized architectures.

Labs: Gaussian elimination by hand, using a package, using a parallel processor.

CS2: 88

• Data structures and abstraction (5 weeks): data structures (stacks, queues, trees), ADTS, specifications, design issues (speed, storage, flexibility), applications in computer science (parsing, activation records, queueing).

Labs: prove that an ADT implementation is correct, utilize an ADT implementation, con- trast competing implementation strategies (array versus linked list) for an ADT, define and implement a new ADT.

• The limits of computability (3 weeks): Turing machine, O-notation and complexity, NP-COm- pleteness, intractable and unsolvable problems.

Labs: exercise several Turing machines (using a simulator), corroborate theoretical complexity estimates empirically, design and implement an intractable problem.

• Operating systems and security (3 weeks): definition; processes, scheduling, context switching; memory and device management; security and protection.

Labs: design and implement a set of cooper- ating processes; design command scripts to manipulate files in a hierarchical system; design a command script that solves a simple protection problem.

• Distributed computing and networks (3 weeks): distributed computing; loosely and tightly cou- pled architectures (shared memory and message passing, remote login, remote file systems, elec-

A.B. Tucker and D.K. Garnick / Introductory curriculum in computhlg 53

tronic mail); intermachine communication (lo- cal versus long-haul networks).

Labs: use network services to find a target file in a distributed system; measure the effects of concurrency of access on the perfor- mance of a distributed database system.

CS3:88

• Models in artificial intelligence (5 weeks): goals, limits and prospects for AI; expert systems, rule-based inferencing; natural language understanding, speech, vision; managing complexity in AI systems.

Labs: develop some Lisp programs for sym- bol manipulation, build and exercise a simple rule-based system, exercise a larger existing system and investigate problems of complexity.

• File and database systems (3 weeks): file systems, models of database systems (relational, network), secondary storage devices and inter- faces.

Labs: design a simple relational database application; write queries in a query language for a given database system; design and implement a hashed or indexed file, including commands for creation, update, retrieval.

• Parallel computation (3 weeks): synchronization primitives, mutual exclusion, deadlock; hardware models (SlMD, MIMIC, systolic, data- flow); fine-grained parallelism, theoretical limits for speedup with parallelism.

Labs: exercise the dining philosophers problem; develop parallel solutions to well-known algorithms (sorting, graph algorithms); use a simulator for a machine like the connection machine.

• The human interface (3 weeks): problem definition (naive versus expert users); screen graphics concepts (plane, point, line, etc.); hardware devices for graphics (bit-mapped, mouse, tablet, voice); anatomy of an application (model-view- controller design).

This model was presented as an existence proof that an introductory curriculum in computing could include broad disciplinary coverage and still cover certain fundamental topics in greater depth than others. It is also distinguished by the pres- ence of laboratory experiments that include experimental and analytical work in a variety of subject areas, not just in programming.

While this model is as yet untried, its ideas differ sharply from those that now dominate the introductory course and lead to the conclusion that computing = programmhlg.

tVhat theory for the introductory courses?

The idea of recasting the notion of computing as very large-scale application of logic, or VI_SAL, was recently proposed in [14]. That idea is based on the definition of computing as the application of formal methods to solve problems. Dijkstra's text, A Method of Programmhtg [13], shows how logic and proof can be combined constructively with the development of programs to solve problems. This text is intended for students at the level of a CSl course.

In 1989 and 1990 SIGCSE panel discussions [29,30], we proposed that the discrete math course be dismembered and its constituent topics be distributed among the three courses in the introductory sequence. The idea here was to reaffirm the ideas of Dijkstra, Ralston and others [17,22], that

Table 4 Distribution of Discrete Math across four courses: a simplified view

Current Discrete Math: Sets, Functions, Logic,

Proof, Recursion Combinatorics, Complexity, Trees Boolean algebra, Finite state.automata Graph theory, Matrices

Proposed CSI: Sets, Functions, Logic, Proof, Recursion, CS2: Combinatorics, Complexity, Trees, CS3: Boolean algebra, Finite state automata, CS4: Graph theory. Matrices, Proof,

CS1: Pascal programming

CS2: Abstraction, Data structures, Sorting CS3: Computer organization

(less) Pascal programming Abstraction. Data structures. Sorting Computer organization Algorithms


theory is so pervasive across the discipline that students ought to be exposed to theoretical material as soon as it naturally arises in the introductory curriculum. Table 4 summarizes this proposal in a simplified fashion.

The advantage of this proposal is that it changes the introductory curriculum in a fundamental way. It clearly disassociates CSl from its former identity as the programming course, and connects the theory (functions and logic) with those topics (programming) in which it is employed. Similarly, cs2 unites the subjects of recursion, combinatorics and trees with data structures, abstraction and complexity; cs3 unites Boolean algebra and finite state machines with computer organization; and cs4 unites graph theory with the study of algorithms.

The roles of laboratories and design

The previous task force report [12] also identified a new dimension for the laboratory component of the curriculum. Its suggestions move the curriculum away from the open programmhlg assignment as the usual laboratory experience and toward the inclusion of more scientific (experimental) and design activities in a closed, supervised and regularly scheduled type of lab session. The integration of particular non-programming laboratory experiences with lecture material i.s explicitly shown in the above description of introductory courses CSl : 88, cs2: 88, and cs3 : 88.

More recently, the AC~,I/IEnE CS Joint Curricu- lum Task Force [3,4] has developed a more detailed statement about the rfle of laboratories in the undergraduate curriculum. This statement defines the notions of closed lab and open lab as two separate kinds of activities. The former is a scheduled, supervised event, while the latter is an unscheduled programming assignment of the more traditional variety. Closed labs provide settings in which students can perform various kinds of ana- lytic experiments, using simulators and other hardware and software tools, arrive at conclusions and write a lab report on their findings, in the same way that a chemistry or physics laboratory would be conducted. Open labs provide settings in which computing assignments that require more than a fixed, scheduled amount of time, can be completed. These, for instance, are appropriate settings for various kinds of conventional program design and software projects to be completed.

The nature and rrle of design in the curriculum

has also been developed in more detail by the present task force. That is, programming is viewed as part of a larger design process that includes a number of additional parts beyond the discovery and coding of an algorithm in a programming language. These parts parallel those of the traditional software lifecycle model requirements, specifications, design, implementation (coding), verification and maintenance.

From the point of view of the introductory curriculum, therefore, the details of coding an algorithm in a programming language can be addressed in a scheduled weekly laboratory project. Such a project parallels the week's lectures, which can concentrate on more fundamental principles of the discipline; algorithm discovery, verification, design methodologies and so forth.

Emergence of a social and ethical dimension

The present task force maintains that a number of fundamental social, ethical and professional issues ought to be covered by undergraduate major programs in computing. Traditionally, these topics have been relegated to the status of elective (course cs9 in Curricuhtm 78), and in practice have been largely ignored.

We believe that such topics ought to be required of all majors in computing, beginning at the introductory level. Thus, majors ought to become well-informed about such subjects as the following: - copyr ight /pa tent status of hardware, software

and algorithms; - software error control and risk management; - security and protection of systems and data; - database accuracy, access and privacy issues; - a r t i f i c i a l intelligence: goals, limits, and pro-

spects; - social impact of computer networks.

The question of where and how these subjects can be best introduced into the introductory sequence in the computing curriculum remains to be answered. In the next section, we present one model for accomplishing this.

A b r e a d t h - f i r s t m o d e l f o r the introductory s e -

q u e n c e

In an attempt to redefine the introductory sequence in a way that would truly introduce the

A.B. Tucker and D.K Garnick / Introductory curriculum hr computing 55

discipline as a whole, replete with theory, we have proposed a four-course introductory sequence [27]. We denote these courses as CSl : 90-cs4: 90. In this section, we describe the goals for the design of this sequence, describe the courses in some detail and discuss the implications of the model.

Goals

The importance of the theoretical component of the discipline has gained recognition as curricula have evolved. However, when theory at the introductory level is relegated to a separate course (Discrete Math), and even to a separate department, students rarely draw the strong connections between theory and its place within the discipline. Students are not likely to appreciate the importance of theoretical material if it is taught in vacuo, nor are they likely to understand technical material in depth if it is presented in the absence of its theoretical basis. Thus, a major goal of the new model is to connect theory directly with abstraction and design whenever it naturally occurs in the curriculum.

Another major goal of our model is to provide the introductory sequence a richer introduction to the breadth of the discipline of computing. One must take care not to confuse this approach with a "topics on parade" style of introduction. Below, we describe an introductory sequence in which each course is designed around unifying principles that run through the discipline. By following a set of principles through their appearances in theory, abstraction and design, each course is able to touch on several areas of computing in a coherent fashion. This approach is orthogonal to the way that advanced courses are designed, but is con- sistent with introductory courses in other disciplines.

Traditionally, introductory sequences have focused more on the tools of the discipline (programming) than on the underlying principles of the discipline. This is much like basing a first course in chemistry on. beakers and burners. This is not to say that programming skill is unimportant. Class time should be devoted to covering principles; structured laboratory exercises provide the right setting for students to learn how to use the tools of the science, and to see how those tools can be used to explore the phenomena of the

science. Thus, a third goal of the proposed model is to add a laboratory science dimension to the curriculum.

Computer technology gives individuals the means to invade privacy, disseminate information and disrupt society on a scale that was previously impossible. It is now imperative that students leave school with an understanding of the social and ethical issues surrounding computing. Curricuhml 78 proposed an advanced elective to address this need. However, such a course is not required in typical curricula. Further, it is not likely that students will see the strong connections between the technical and social issues if they are presented in distinct courses. Thus, a fourth goal of the model is to add a social issues dimension to specific topics as they occur in the curriculum.

Content

This section summarizes the content of this four-course introductory sequence.

CSl: 90, Logic, Programming and Computers Theory: sets, functions and logic. Abstraction: algorithms, programs, verification. Design: registers, yon Neumann machine model,

assembly language. Social context: copyrights, software piracy, defini-

tions of "publ ic domain," etc., legal implications.

cs2:90, Abstraction, Data Structures and Software Systems

Theory: combinatorics, complexity and graph theory.

Abstraction: abstract data types and data structures: stacks, queues, trees.

Design: implementation of data structures; software design principles; applications in large software systems (an operating system overview).

Social context: the ethics of team projects; intellectual property; reliability and security of large systems; vulnerability, the limits of complexity; the SDZ debate.

CS3:90, Levels of Architecture, Languages and Ap- plications

Theory: finite and pushdown automata, regular context-free languages.

Abstraction: review the von Neumann machine


model, neighboring levels--microprogramming, macro-assembly, operating system levels; i /o, processes, interrupts.

Design: functional languages and artificial intelligence applications; file and database systems, languages and applications; graphics principles.

Social context: the AI debate--myth versus reality; computer databases--accuracy, access and privacy.

cs4:9o, Algorithms, Concurrency and the Limits of Computation

Theory: continuation of graph and complexity theory; NP-completeness, tractable, intractable and unsolvable problems (halting and tiling problems).

Abstraction: basic graph algorithms; search, traversal, shortest paths, connectedness; design strategies--greedy, divide-and-conquer, back- tracking; hard problems--knapsack problems, matrix multiply, job scheduling, traveling sales- man, eight queens, graph coloring, minimum spanning trees; mathematical algorithms.

Design: distributed computing and networks, parallelism and concurrency in algorithms, analysis and verification of parallel algorithms.

Social context: social impact of networks; crime and electronic mail; patentability of algorithms; reliability of mathematical algorithms.

Detailed examples from this model

The following examples are intended to show how the subject matter in these courses can be so organized that: (1) the four dimensions of the discipline--theory, abstraction, design and social context--can be integrated in a coherent way; and (2) the scheduled weekly laboratory experience can be integrated with the lectures so that technical details are well-covered and principles are reinforced by experimental results.

parts of the course: programming and architecture.

In the programming part of the course (approximately six weeks), program design is based upon precise specifications (preconditions and postconditions) expressed in the language of mathematical logic. Classical methods of program composition by stepwise refinement are developed with this level of rigor--that is, one step's postcondition is identified with the next step's precondition. The precision of logic also allows the idea of program verification to be introduced alongside the program development process.

The computer architecture part of the course (approximately four weeks) contains a unit on the design of basic circuits from logic gates. Thus, the fundamental nature of mathematical logic on the architecture side of the discipline is also exposed early in the curriculum.

Weekly scheduled laboratory assignments accompany all of these course topics. For instance, one lab will provide students with a simple program and a set of specifications--preconditions and postconditions--and ask them to validate the program empirically. That is, they run the program with a suite of test input data and ex- amine the correspondence between precondition satisfaction and postcondition satisfaction. This exercise can be accompanied by a written assignment in which students are asked to verify the program. By applying the rules of logic and proof, students should be able to reason through the steps of the program to ascertain that it satisfies its postcondition for all inputs that lead to program termination.

The legal facts and ethical principles that sur- round software copyrights and hardware patents are also covered in the last week of this course. Students' laboratory work quickly exposes them to the ease with which software can be copied; and thus provides ready examples of the larger legal and ethical dimensions of software.

Example 1: integration of logic, programming (specification and design), computer architecture and copyright issues.

The first course in the above model begins with a three-week introduction to mathematical logic: propositions, variables, truth tables, rules of in- ference and proof by induction. This theory is fundamental to two separate subjects in latter

Example 2: hltegration of graph theory, data structures, operating systems, networks and system security issues.

The mathematical definitions of graphs, connectedness, directedness, traversal, and so forth, are introduced in the first part of the second course. There, they form a principled foundation upon which the fundamental data structures

A.B. Tucker and D.K. Garnick / lntroductoo, curriculum in computing 57

(graphs, trees, stacks and queues) of the discipline and their abstractions can be developed.

Applications of data structures abound in computing, especially in the areas of operating systems and networks--print queues, directory trees and so forth. Thus, a general overview of operating systems and networks can reasonably follow in this context, and provide another example of the coherence of theory, abstraction and design in the discipline of computing.

Social dimensions of these subjects include system security and viruses, whose principles and applications readily follow from the introduction to operating systems principles.

Scheduled weekly laboratory exercises in this course allow students to experiment with existing software, as well as develop their own. For instance, early experience with distr ibuted, hierarchical file structures can be gained from a lab exercise that requires students to search for and locate specific files in a networked collection of UNIX machines.

Example 3: hltegration of complexity theory, algorithms, software engineeringo and feasibifity and reliability of large software systems.

Another theme of the second course begins with the mathematical notion of combinatorics and complexity, and ends with a discussion of the feasibility and reliability of large software systems.

The analysis of various algorithms--sorting, searching and traversal--follows the introduction to complexity. More complex levels of algorithm behavior--polynomial, intractable and unsolvable problems--are introduced using classical examples.

Scheduled weekly laboratory assignments allow

students experimentally to derive or validate the complexity of common and uncommon algorithms - - fo r instance in sorting. For example, in one lab, students may measure the run time of a sorting algorithm for various sizes of randomly obtained input, and then use mathematical curve-fitting software to determine the complexity of the algorithm. This measure can then be compared with the theoretical complexity of the algorithm that had been derived in class.

Laboratories here are also fertile grounds for students to become familiar with the software design process that allows computer scientists and engineers to deal with the development of large, complex systems. Case studies, such as the SDI debate, can be read by students so that they gain a sense of the limits and fallibility of complex software systems.

Strengths and weaknesses

The major strength of this four course introductory sequence is that it unifies the four main themes of the discipline--theory, abstraction, design and social context-- in such a way that their complementarity is clearly introduced and reinforced. Current curricula are particularly weak in theoretical and mathematical content, especially at the introductory levels. Attention to abstraction and design is adequate, while attention to social issues is nearly non-existent; a minor exception is [16]. A comparison of Table 3 with Table 5 il- lustrates this difference.

A secondary strength of this sequence is that it covers the discipline of computing broadly. Upon finishing all four of these courses, students will have achieved a broad view of all nine subject areas that make up the discipline. Current cur-

Table 5 Discipline coverage by the proposed sequence: CSI : 90, CS2 : 90, CS3 : 90, CS4 : 90

Theory Abstraction Design Social context

Algorithms & data structures Programming languages Architecture Numerical & symbolic computing Operating systems Software methodology & engineering Database & information retrieval Artificial intelligence & robotics Human-computer communication

CS2, 4 CS2, 4 CS2, 4 CS2 CS3 CS3 CS1 CS1 CS1, 4 CS3 CS4 CS4 CS1

CS2, 4 CS1 CS1, 2 CS1, 2 CS1

CS3 CS3 CS3 CS3

58 A.B. Tucker and D.K. Garnick / Introductory curricuhLm in computing

ricula do not even guarantee that such a view is achieved upon completion of the entire major. Their introductory courses are particularly notable for narrowness of focus on programming and data structures. Again, compare Table 3 with Table 5.

A third strength of this proposal is that it defines more precisely the rrle and content of the laboratory experience in each of the courses. Stu- dents have an opportunity to view computing from its experimental scientific and design points of view, and not just as places where they write and debug programs. If computing is to be viewed as a science, students must see exactly how and where within the discipline its scientific dimensions are essential--beginning with the first course.

When seen from the point of view of traditional models for CSl and cs2, this proposed sequence might be perceived to be weak in the amount of programming experience that students will gain. However, its inclusion of scheduled weekly laboratory exercises tends to compensate for this weakness. That is, if the proposed sequence were to use the traditional, unscheduled laboratory assignments, it would indeed be weaker in its programming component than the traditional CSl and cs2 courses. But it does not. Many of the weekly laboratory sessions are devoted to elements of programming language syntax-- loops, procedures, parameters, arithmetic expressions--that are currently taught in the lecture parts of the course. These syntactic elements are important, for sure, but they should not burden the course to such an extent that it is reduced to an introduction to programming in language X. Students are increasingly computer literate when they enter college, and CSl courses that dwell excessively on the technical elements of language syntax are boring and unrepresentative of the underlying principles of the discipline that may become their major.

Another possible weakness of this proposal is that it could eliminate from the curriculum the need for a traditional discrete mathematics course, in favor of spreading the topics of discrete mathematics among the four courses in the introductory sequence. Some implementations of this model will see that as an advantage rather than a disadvantage. Others may, however, decide not to eliminate discrete math at all. They may instead use the theoretical parts of the four courses described above as an opportunity to review important topics in discrete math, on the grounds of

the reinforcement that students gain from spiral learning.

Pragmata

Several real practical considerations follow if this proposed curricular change is to be effectively implemented. They include: - textbooks; - faculty development; - laboratory exercises and software development; - the intermediate and advanced curriculum; - service courses for non-majors; - the advanced placement curriculum.

The most serious of these concerns is that no textbooks or laboratory materials yet exist for supporting the introductory curriculum in the particular way that this kind of four-course sequence suggests, although at least one such project is now underway [27]. The texts cited in the foregoing section are designed to cover only a single course (CSl or cs2). The Stanford curriculum cited above is supported largely by faculty-developed lecture notes and laboratory experiments, alongside a one-semester text [16]. Authors of future texts will need to think more globally about how that course fits into the whole computing curriculum. In addition,.successful curricula will depend on csl laboratory manuals that coordinate scheduled lab exercises with class material.

Faculty will need time to integrate theory and broad subject matter into the introductory courses. They may be reluctant to explore new approaches without appropriate incentives in the form of course development stipends and time to par- ticipate in workshops.

Revision of the introductory curriculum will surely have ripple effects on certain intermediate and advanced courses in the undergraduate curriculum. While it is beyond the scope of this paper to evaluate this impact in detail, we refer readers to the work of the ACM//IEEE CS Joint Curriculum Task Force [3,4]. This task force is developing a model for undergraduate curricula in computing that does address the entire curriculum, and for a variety of different institutional settings.

The service courses in computing for non- majors have traditionally fallen into two cate- gories: (1) an intensive introduction to programming,

primarily for science and engineering majors;

A.B. Tucker and D.K: Garnick / Introductory curriculum in computing 59

(2) a computer literacy course, which emphasizes using computers as tools (spreadsheets, graphics, word processing, etc.), alongside a study of the uses of computers in society.

The need for an intensive programming course by a non-major has often been met by taking the traditional CSl course itself. On the other hand, the need for a computer literacy course is rarely met by the traditional CSl course; that type of course is typically a separate offering, and is even sometimes team-taught by non-computing faculty.

If CSl were to be revised along the lines suggested in this section, it probably would not meet either of these two needs directly. However, it might emerge as a more substantive replacement for the second course above; it does address certain social and ethical issues, and it broadly pre- sents computing as a scientific discipline.

Finally, this kind of revision of the introductory sequence will have significant impact on the advanced placement curriculum. Its main influence would be to add more architecture and theory to that curriculum, and delete some programming. Thus, secondary school students who are taking computing would receive a broader view of the discipline--much as they now do in the AP curricula for chemistry, physics and other disciplines. This is probably a healthy change.

Conclusions: where can we go from here?

For the proposed curriculum to be implemented, serious developments efforts will need to be made over the next few years. Foundation support will be needed, so that the first wave of experimentation can be mounted and assessed. Consortia, such as the Pew-supported undergraduate science education clusters, can rally around specific efforts by providing class-testing for early efforts.

The need for serious rethinking of the introductory courses in computing is great. The discipline has a fresh new definition, yet our introductory courses reinforce the perception that computing =

programmhlg. The above proposal is an effort to contribute to fundamental rethinking about the rr le of the introductory sequence in changing this perception, and in providing a broader, more sci- entifically oriented foundation for educating un- dergraduates in the discipline of computing.

Ackno~vledgements

This work was supported in part by a grant from the Alfred P. Sloan Foundation.

References

[1] H. Abelson and G. Sussman, Structure and Interpretation of Computer Programs (McGraw-Hill, New York, 1985).

[2] ACM Curriculum Committee on Computer Science, Cur- riculum 78: recommendations for the undergraduate program in computer science, Communications of the ACM 22(3) (1979) 147-166.

[3] ACM/IEEE CS Joint Curriculum Task Force. Panel pre- sentations at SIGCSE Technical S)'mposium (February 1989 and February 1990), COMPCON 89 (San Fransisco, CA, March 1989) and NECC (Boston, MA, June 1989).

[4] ACM/IEEE CS Joint Curriculum Task Force, Computing Curricula, 1991 (ACM Press and IEEE-CS Press, New York, 1991).

[5] The College Board, Ad~'anced Placement Course Descrip- tion: Computer Science (College Entrance Examination Board, Princeton, N J, 1989).

[6] J.G. Brookshear, Computer Science: an Ot'er~'iew, 2nd ed. (Benjamin/Cummings, Menlo Park, CA, 1988).

[7] D. Cooper and M. Clancy, Oh! Pascal! 2nd ed. (Norton, New York, 1985).

[8] N. Dale and S. Lilly. Pascal Plus Data Structures (Heath, Lexington, MA, 1985).

[9] N. Dale and C. Weems, Pascal, 2nd ed. (Heath, Lexing- ton, MA, I987).

[10] P. Denning, Educational ruminations, Communications of the ACM 27(10) (1984) 979-983.

[11] P. Denning, The science of computing: what is computer science? American Scientist (January 1985).

[12] P. Denning, D. Comer, D. Gries, M. Mulder, A. Tucker, A. Turner, and P. Young, Report of the ACM Task Force on the Core of Computer Science (ACM Press, New York, 1988). Portions reprinted in Communication of the ACM 32(1) (1989) and Computer (March 1989).

[13] E. Dijkstra and W. Feijen, A Method of Programming (Addison-Wesley, Reading, MA, 1988).

[14] E. Dijkstra, On the cruelty of really teaching computing science, Communications of the ACi~f 32(12) (1989) 1398- 1404.

[15] N. Gibbs and A. Tucker, A model curriculum for a liberal arts degree in computer science, Communications of the ACM 29(3) (1986) 202-210.

[16] L. Goldschlager and A. Lister, Computer Science: a Mod- ern Introduction, 2nd ed. (Prentice-Hall, Englewood Cliffs, NJ, 1988).

[17] P.B. Henderson, Discrete mathematics as a precursor to programming, The Papers of the Technical Symposium on Computer Science Education (ACM, February 1990).

[18] E. Koffman, Problem Solving and Structured Programming in Pascal, 2nd ed. (Addison-Wesley, Reading, MA, 1985).

[19] E. Koffman, P. Miller and C. Wardle, Recommended Curriculum for CS1 : 1984, Communications of the ACM 27(10) (1984) 998-1001.


[20] E. Koffman, D. Stemple and C. Wardle, Recommended Curriculum for CS2:1984, Communications of the ACM 28(8) (1985) 815-818.

[21] D.D. McCracken, The role of theory in the undergraduate curriculum. Panel session at SIGCSE Technical Sym- posium (Louisville, KY, February 1989).

[22] J.P. Myers, The central role of mathematical logic in computer science, The Papers of the Technical Symposium on Computer Science Education (ACM, February 1990).

[23] H. Nissenbaum and T. Winograd, Computers. Ethics. and Social Responsibility. Syllabus for CS201, Stanford Uni- versity, CA (Spring 1989).

[24] A. Ralston, The first course in computer science needs a mathematics corequisite, Communications of the ACM 27 (1984) 1002-1005.

[25] C. Schaffer, Principles of Computer Science (Prentice-Hall, Englewood Cliffs, N J, 1988).

[26] Stanford University Computer Science Department, Fundamentals of Computer Science. Course syllabus (Sep- tember 1987).

[27] A. Tucker, J. Bradley, R. Cupper and D. Gamick, Funda- mentals of Computing Volumes I - I V . Draft outline and prospectus, Bowdoin College, Brunswick, ME (March 1989).

[28] A. Tucker, Computer Science: a Second Course Using Modula.2 (McGraw-Hill, New York, 1988).

[29] A. Tucker, Discrete math and the computer science curriculum: some radical ideas. Panel presentation at SIGCSE Technical Symposium (Louisville, KY, February 1990).

[30] A. Tucker, Glacial Progress vs. Dramatic Change in Cur- riculum Design. Presentation at SIGCSE Technical Sym- posium (Washington, DC, February 1990).

[31] J. Warlord, Introductory computer science: the ease for a unified view, The Papers of the Technical Symposium on Computer Science Education (ACM, February 1988) 44-48.

[32] J. Warlord, Computer Science, 6th ed. Notes for Cose 275 & 276 (Pcpperdine University, Malibu, CA, 1986).

Documents

no 10