Course Group Status Report

1. Summary

Three key features of this sequence deserve special mention because they entail significant differences relative to a traditional approach to CS1/CS2 courses:

1. The use of component-based software engineering for the philosophical, theoretical, and technical bases of the sequence.
2. The integrated and unified nature of the course sequence.
3. The recognition that the first CS course at a university is not the first programming experience for most prospective CSE students.

http://www.cis.ohio-state.edu/~weide/sce/now

1. The biology professor can start his first-year course by announcing, "Biology is the study of life. Everything we do in this class is directly related to this theme."  What does the computer science professor announce at this point?  First-year CSE students need to see clearly that computer science as a discipline has an important intellectual role to play and that it offers deep philosophical questions, much like the other hard sciences and mathematics; that CS is not "just programming".  An appropriate intellectual focus for the first year can be built on the foundations of systems thinking and mathematical modeling, as these principles are manifested in a component-based software paradigm.  This is what we try to accomplish, teaching good software engineering principles (not "just programming") in the process.
2. Most computer science educators cannot agree on what a well-designed piece of software should look like; the same is true for practitioners.  This observation is easily supported by examining computer science textbooks, technical papers, and commercial "industrial-strength" software.  Except for egregiously poor design practices, most software engineers and software engineering educators cannot separate fair-to-good software designs from excellent ones.  Beyond the tenets of structured programming there are few accepted community standards for what software systems should be like, at the detail level.  This is particularly true for component-based software.  We have put together a team of faculty and graduate students who share a common vision of software development and how to teach it.  This is essential for a unified and integrated sequence since, otherwise, there is little hope that students will develop the appropriate knowledge and skills over the sequence as a whole.  So we ask students to be open-minded and to try out what we're teaching them for one entire year, not just for one term.  After that they may do as they wish in subsequent courses: continue to use and further develop the component-based software engineering discipline they have learned in this sequence, revert to their previous methods of programming, or learn yet other ones.
3. Students entering CIS221 are expected to have had prior programming experience such as that learned in a high school programming course or in CIS201 "Elementary Computer Programming".  Several times each quarter before registration, we administer a placement exam for admission to CIS221 to students who do not have CIS201 or EG167 or AP computer science credit (a score of at least 3 on the CS/A or CS/AB exam).  In student surveys conducted in 1995-96, we found that about 65% of students in CIS221 at that time had had such prior experience in programming.  This contributed to two serious problems: boredom for many during CIS221, and a signficant "intimidation factor" for the minority who had no prior experience with programming.  We hoped that the prerequisite would help alleviate these problems; but see Section 2.5

As explained later in this report, students and faculty are generally  satisfied with the courses in this group.  Ideas for changes in the sequence always are being considered as a result of constant monitoring of student reactions via SETs (Student Evaluations of Teaching) and via on-line surveys that measure how well the courses meet their stated objectives, how well various pedagogical devices are working, and how student attitudes about various software engineering principles tend to change from beginning to end of the course sequence. 

2. Detailed Analysis

2.1 Summary of the courses

In order to do this purely from the client view, students must understand the components' behavior entirely from their specifications; they are not given and cannot use knowledge of how the components are implemented.  Two current programming projects involve using a "least cost path machine" component to find cheapest airfares, and using a "natural number" component as the basis for a calculator that works with arbitrarily large natural numbers.  In the process of using these components, students are introduced to some classical CS algorithms (Newton iteration, interval halving, fast powering), some classical specification and programming techniques (design-by-contract, programming-by-difference, recursion), and the first pieces of the RESOLVE/C++ discipline for programming in C++ (abstract and concrete classes, extensions, checking components).  They also learn to read simple model-based formal specifications in order to understand what components do.

CIS222: This is a continuation of CIS221 in which the first half still focuses purely on the client view, while the second half introduces the implementer view of components.  The course starts by introducing templates and their two main uses: generalization (e.g., a component that provides sequences not just of characters, like the built-in Text component, but of arbitrary items) and decoupling (e.g., extending the functionality of an existing component in a way that does not introduce a by-name dependency between the new component and the one being extended).  Components introduced here are our versions of standard ADTs for CS2: Sequence, Set, Queue, Stack, Partial_Map, Array, List.  The last project in the first half of CIS222 is one where the students have to select components that they feel are appropriate for the application, and they must develop the entire application on their own without our advice as to what components should be used or how they should be composed.  Currently, this application is to generate an HTML glossary from a text file that contains terms and definitions, where the glossary must have a hypertext link from each occurrence of a term in some definition, to that term's definition.

In the second half of the course, students are introduced to methods for implementing the components they have used in CIS221 and in the first half of CIS222.  For example, currently they implement Partial_Map using hashing, by layering over an Array of Queues; and List using "raw C++" pointers.  Additional classical topics of general interest include an introduction to sorting algorithms, an introduction to loop invariants, and an introduction to algorithm analysis.

CIS321:  This is a continuation of CIS222 that continues the implementer view with more elaborate examples.  Students in this course explore several new components ranging from the general-purpose Binary_Tree and Sorting_Machine to special-purpose components involved in a fairly large multi-week programming project.  Currently, this project involves developing a kind of logic database in which one can add assertions (facts) to the database, and then query the database to find all matching facts.  This project involves several components related to regular and context-free language processing and expression evaluation as well as components introduced in CIS222.  Two-person teams that persist for the quarter give students a "mini-team" experience.  There is considerable emphasis on more advanced uses of recursion and on somewhat more complex algorithm analysis.

2.2 Relation to rest of the program

Math366 "Discrete Mathematical Structures I" is a corequisite for CIS321.  This course has a checkered history.  Over the past few quarters we have met several times with the Mathematics faculty who are responsible for Math366, hoping to improve it by leveraging on the fact that CIS221 and CIS222 students coming through the new software component engineering sequence have already had some experience reading formal specifications.  It turns out, though, that Math366 is taken by many other students who have not had any exposure to logic and discrete mathematics and who do not appreciate their potential utility.  This seems to bog down the pace of the course.  The Mathematics faculty has offered to pilot a CSE-majors-only section of Math366 to determine whether there would be any advantages to separating the course into two different courses.  This pilot originally was to have been tried in Sp99, but various problems in getting started have delayed the plan, probably until at least Au99.  We will continue to pursue improvements to Math366.

CIS321 is a prerequisite for the various CIS459 "Programming Languages for Programmers" courses.  For most of these there is no problem.  However, it has recently come to our attention from student remarks on the cis.undergrads newsgroup that CIS459.21 "Programming in C" is assuming far too little of the students who enter that course through CIS321.  The problem here is that there is an alternate prerequisite for CIS459.21: CIS314 "Business Programming with File Processing", which is taken by students in the College of Business in the Information Systems track.  So long as students can come into CIS459.21 from that path (having learned Pascal) it seems impossible to make the course interesting and useful to students who have come through CIS321.  Advisors should be reminded to advise students that CIS459.21 might not be the best choice of CIS459's for CSE majors; CIS459.22 "Programming in C++" or CIS459.23 "Programming in Java" are probably better.

On the other hand, CIS459.22 currently has both CIS321 and CIS459.21 as prerequisites.  The latter prerequisite is clearly a leftover from the days when the introductory courses used Modula-2.  We recommend making the prerequisite just CIS321 (without CIS459.21), and beefing up the course to take advantage of the fact that students coming out of CIS321 already know a good deal about C++.  CIS459.22 should concentrate on illustrating differences encountered when adopting more traditional ways of using C++, not on the syntax of the language assuming that students haven't seen it before.

CIS321 is also a prerequisite to CIS560 "Systems Software Design, Development, and Documentation", which is seen from a prerequisite chart to be the keystone course in the entire CSE program.  In CIS560, students work in 4-5-person groups on 2-3 fairly large systems-programming projects.  They may use any language they wish for these projects.  In particular, they need not use C++ following the RESOLVE discipline.  According to our surveys of CIS 560 students, only about a third of all teams choose to use RESOLVE/C++.  Two reasons typically are cited for not using it: the desire to learn a new language, typically Java or C, at a deeper level than in CIS459 courses; and the desire to use "ordinary" C++ and to disregard the RESOLVE discipline, either because it is considered too restrictive or because some other group members did not know it.  Earlier this quarter we met with a group of current and recent CIS560 instructors and the CIS560 course coordinator to discuss specific problems students using RESOLVE/C++ seem to have in CIS560.  Most problems arose because students were unaware of features of RESOLVE/C++ that had not been used through CIS321 (e.g., the ability to check file permissions), or because there was little help available to them from the CIS560 instructors or graders (who, as it happened, were themselves not experienced with RESOLVE/C++).  Later we met again with the current CIS560 instructors to show them specifically what assignments students do in CIS221, CIS222, and CIS321, and to demonstrate how students can get information about RESOLVE/C++ on-line and help from the cis.lang.rcpp newsgroup.  Some of these resources may not have been available when the current CIS560 students took CIS221, CIS222, and CIS321, because there is frequently a lag of several quarters between CIS321 and CIS560 because most students work part-time, take co-op positions, etc.  Our hope is therefore that this problem will become less important over time.  Meanwhile, we will continue to monitor student choices and difficulties in CIS560.

Apparently there are no issues in terms of prerequisite fulfillment for the other courses that directly require CIS321, namely CIS570 "File Design and Analysis" and CIS625 "Introduction to Automata and Formal Languages".  CIS680 "Data Structures" (one link farther down the line), however, needs to be changed as a result of the changes to CIS221, CIS222, and CIS321.  Historically, many principles introduced in the new software component engineering sequence have been taught in CIS680.  This was fine as long as students in CIS 680 were coming through the old version of CIS221, CIS222, and CIS321.  Now that many students from the new sequence have reached CIS680, though, it is appropriate to change CIS680 to take advantage of this.  In fact, such a change is already underway.  A pilot version of CIS680 that emphasizes algorithm design and analysis and that builds on the experiences of students in the software component engineering sequence was piloted in Wi99 under the leadership of Prof. Rafe Wenger.  Initial feedback from students and instructor suggest that CIS680 can and should be changed in this direction.

2.3 Relation to program objectives

2.3.1 CSE Objectives

In all three courses, students are required to demonstrate proficiency in the areas of software design and development and algorithms (1a), and to apply these principles and practices to a variety of problems (1c).  Of course, at this level of the curriculum the designs and algorithms are necessarily rather simple compared to what seniors might encounter.  But the software engineering principles needed to do those larger projects are acquired starting in CIS221.

In all three course, but especially in CIS321, students must demonstrate proficiency in relevant aspects of mathematics, including discrete mathematics (1b).  They learn to read and to use formal specifications starting in CIS221.  These specifications involve several discrete math theories -- sets, strings, functions and relations, graphs -- and, in CIS321, regular and context-free grammars and languages.

CIS221 uses a couple lab assignments involving root-finding, in which students use an understanding of differential calculus (2a).  By emphasizing partner activities in all three courses both in lecture/activity and closed lab sessions, and by having two-person teams do the main CIS321 project, we give students the opportunity to develop their abilities to work with others in both classroom and laboratory environments (2b) and to develop their communication skills (3a).  In fact, all three courses explicitly emphasize that computer science is largely about communication: the study of techniques for making precise and understandable descriptions of things.  That is, the subject matter of CS involves the study of communications between humans/computers and humans/computers in all four combinations; software engineering in particular inevitably requires considerable attention to human-to-human communication which is precise and understandable and (as students learn from the team experiences) civil.  We raise student consciousness of social, professional and ethical issues related to computing (3c) by assigning readings in CIS221 that relate to, e.g., the Y2K problem, licensing of software engineers, and other contemporary issues related to software-system safety; by emphasizing that software must be correct because human lives literally depend on it; and by having students spend considerable effort on systematic testing of their software (e.g., with closed-lab "testing contests" and a variety of homework assignments).  Finally, by emphasizing principles that have withstood the test of time and downplaying current fashion with respect to languages and whiz-bang tools, we support the development of students' successful careers in high-technology computer-related positions (4a) and their preparation for graduate study (4b).

The contributions that these courses make toward meeting various CSE objectives are summarized in the following table:
 

2.3.2 ABET Criterion 3

Section 2.3.1 explains how all three courses contribute strongly to developing the student's ability to design a system, component, or process to meet desired needs (3c), and to use techniques, skills, and modern engineering tools necessary for engineering practice (3k).  It also suggests how they contribute moderately to the student's ability to apply knowledge of mathematics, science, and engineering (3a), and to identify, formulate, and solve engineering problems (3e); and how they contribute in a limited way to the student's ability to function on teams (3d), to the understanding of professional and ethical responsibility (3f), and to the ability to communicate effectively (3g).

In all three courses, the emphasis on systematic reasoning about software behavior, and especially on systematic testing, results in students beginning to develop an ability to design and conduct experiments and to analyze and interpret data (3b).  There is a closed lab in which timing experiments reveal interesting and seemingly anomalous phenomena (e.g., quicksort appears to run slower than selection sort on some inputs) which students must interpret and explain.

All these courses stress the need for, and an ability to engage in, life-long learning (3i) by requiring the students to learn things like HTML on their own in order to do several of the lab assignments.  Moreover, the course materials available for all three courses currently read far more like reference manuals than like tutorials when it comes to figuring out how to write programs in RESOLVE/C++.  This is quite like "the real world".

The contributions that these courses make toward meeting various ABET objectives are summarized in the following table:
 

2.4 Feedback

• There must be prompt and careful grading of the homework assignments and lab assignments.  At the beginning of each quarter we now make sure graders are aware of their obligations in this regard, and some have not been rehired as a result of their failure to live up to those obligations.
• The course materials are incomplete and hard to read.  Indeed most of these materials are in draft form still because of the experimental nature of the sequence, so we are constantly making improvements in this area.
• The course content, in the opinions of some students, does not acknowledge the "reality" that employers want students who can do amazing bit-twiddling in C or Java.  We are standing our ground on this issue because we believe it is more important to teach principles than programming language syntax and hacker's tricks.

• The attitudinal survey is intended to help us measure changes in student attitudes about various software engineering issues from the beginning of the sequence to the end.
• The pedagogical techniques survey is intended to help us evaluate some of the pedagogical techniques we have tried in the sequence, some of which are rather novel for CS courses (e.g., the use of active-learning techniques, and the use physical manipulatives to illustrate mathematical theories and to explain formal specifications) and some of which are more typical (e.g., team activities for all closed lab and for some open lab assignments).
• The course objectives survey is intended to help us determine which specific course objectives are being met well and which are being short-changed.

http://www.cis.ohio-state.edu/~weide/sce/evaluations

2.5 Possible changes

Some of the lab assignments in all three courses are getting stale, and we are currently developing some new ones that are more interesting and (we hope) more exciting yet still convey the principles effectively.  Our annual attendance at SIGCSE meetings has given us several ideas for how to do this.  Some other changes in assignments (in fact, even moving some material among the three courses) are necessitated by the impending move of these courses from the HPs to the Suns. These changes will be made over the rest of this quarter and during Su99.

Despite the prior programming prerequisite for CIS221, two problems mentioned in Section 1 that we hoped to address -- boredom for relatively advanced students in CIS221, and a signficant "intimidation factor" -- remain problem areas.  There is still an astonishingly wide range of backgrounds and abilities represented in CIS221.  Since the course sequence is integrated and some aspects of CIS221 (e.g., formal specifications, recursion) are new to essentially everyone, we are not convinced it is appropriate merely to offer examination credit for CIS221 because these important topics might never be learned properly by students who skip CIS221.  We continue to seek ways to address the wide spectrum of student backgrounds more effectively.

A nagging problem is the lack of a simple set of instructions for students to work on their CIS221 labs remotely. This is not really something specific to this course; it's just that this course is the students' first exposure to the CIS computing facilities and many of them have trouble getting everything to work because generally they need to install and set up an X server, ssh, etc. We recommend that someone on the IICF staff be assigned to assist us with developing these instructions, preferably this summer as we switch platforms to the Sun servers.

Longer term, we need to look more carefully at integrating CIS560 into the sequence.  An obvious missing piece is that students do not actually design their own components in CIS221, CIS222, and CIS321.  They design implementations of components, but they do not design component interfaces, even though the principles for such design are discussed throughout the sequence.  There is not enough time in a one-year sequence to add this.  But if CIS560 were a smooth continuation of the existing sequence, we believe component interface design could become part of that course yet still allow CIS560 to serve its many other important roles.  Any attempt to incorporate CIS560 will require additional (no doubt external) funding and probably additional personnel because the investment required to make everything work together would be substantial.

Staffing Concerns

Dealing with staffing of the software component engineering sequence has been a constant source of concern and a significant time sink for the course coordinators.  As with all other CIS courses, enrollment in each section of CIS221, CIS222, and CIS321 is limited to 40 students.  Demand for CIS321 can be controlled (roughly) by the department's enrollment management policy -- currently a minimum cphr for admission to the major -- combined with "M" sections to give scheduling priority to majors.  By this mechanism we have been able to get by with 7-8 sections of CIS321 per year because students may become majors before taking CIS321 and, in fact, the course effectively is now limited to those who actually have become majors.  There is no similar way to control enrollments in CIS221 and CIS222, though.  Indeed we do not want to limit enrollments in these two courses because they are required for students before they may even apply for the CSE or CIS major.  We have, therefore, been offering about 18-20 sections of CIS221 per year and about 13-14 sections of CIS222 per year just to meet demand (and there are still many closeouts that delay some students' enrollment by a quarter).

Staffing is a problem because enrollment demands across-the-board in CIS courses limit the number of faculty available to teach CIS221 and CIS222.  In the 1999-2000 academic year, probably 4 sections of CIS221 and 6 sections of CIS222 will be taught by faculty (including lecturers), with the remainder taught by GTAs.  In 1998 we advertised for additional permanent instructional staff to help in this area, and interviewed two candidates, but did not hire anyone.  So we continue to rely on GTAs.  Fortunately, many of these GTAs are experienced with the material and with teaching and do an excellent job.  But each year we have to identify and train several new GTAs for CIS221 and CIS222.  The training typically involves sitting in on, and grading for, a CIS221 of CIS222 section taught by an experienced instructor before the GTA teaches his/her own section.

It has been suggested that we might try large sections of CIS221 and CIS222.  These could be taught by regular faculty, with small recitation sections led by GTAs with little formal training, as at most other universities.  We have resisted this because it is not clear that the GTAs would not need to have nearly the same training as now, because the course material is new even for most GTAs; and we have used the relatively small class sizes in CIS221 and CIS222 as a selling point for OSU to outstanding students who are also considering attending other universities that run large lecture sections of their CS courses.  As mentioned above, Prof. Tim Long has been developing some new materials for CIS221 (piloted in Sp99) that will make the course entirely activity-based with no lecturing at all.  If this succeeds, then there will be no significant advantage to the large-section approach because the GTA training required would be the same in either case.

What we really need to address the staffing problems in these courses is more permanent faculty who can teach them, and it is simply very hard to hire such people in the current market.

3. Conclusions

People involved in preparing report: Paolo Bucci, Tim Long, David Mathias, Mary Beth Lohse, Elley Quinlan, Bruce Weide.

Date of report: April 29, 1999 (revised May 12, 1999)