| Course | Title | Credit Hours |
Required (R)/ Elective (E) |
|---|---|---|---|
| CSE 221 | Software Development Using Components | 4 |
|
| CSE 222 | Development of Software Components | 4 |
|
| CSE 321 | Case Studies in Component-Based Software |
4 |
|
Three key features of this sequence deserve special mention because they entail significant differences relative to a traditional approach to CS1/CS2 courses:
http://www.cse.ohio-state.edu/sce/now
As explained in detail in Section 2.3, courses in this group help us meet a number of ABET Criterion 3 (hence CSE) outcomes. Briefly, students are required to design and implement application programs using ideas from calculus, discrete mathematics, formal languages, etc., ensuring that these courses contribute to meeting ABET outcomes 3a, 3c, and 3e; students work in four-person activity teams in class in CSE 221, work in two-person teams during lecture/activity sessions and closed lab sessions in all three courses, and work in two-person teams on a fairly large project in CSE 321, so these courses contribute to meeting 3d and 3g; there is substantial emphasis on evaluating program correctness both by reasoning and by systematic testing, and frequent discussion of the societal consequences of incorrect software, which contributes to meeting 3b, 3f, and 3k; in order to do certain lab assignments, students have to learn some things entirely on their own (e.g., HTML), thereby contributing to meeting 3i; and the range of modern techniques and software engineering concepts that the students work with in these courses help these courses contribute to meeting 3k.
Students and faculty are generally satisfied with the courses in this group. However, ideas for changes in the sequence always are being considered as a result of constant monitoring of student reactions via SEIs (Student Evaluations of Instruction), as well as discussions with faculty who teach successor courses (especially CSE 560).
CSE 222: This is a continuation of CSE 221 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 CSE 222 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 CSE 221 and in the first half of CSE 222. For example, current lab assignments involve implementing a Partial_Map component using hashing, by layering over an Array of Queues; and two different List components using "raw C++" pointers. Additional classical topics of general interest include an introduction to loop invariants, and a little bit of continuation of the introduction to algorithm analysis started in CSE 221.
CSE 321: This is a continuation of CSE 222 that reinforces techniques for the implementer 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 compiler for a small Pascal-like programming language that is used to program the behavior of "bugs" in a "Bugs World" game/simulation. This project makes use of several components related to regular and context-free language processing and code generation as well as components introduced in CSE 222. 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 sophisticated algorithm analysis, including a comparative treatment of sorting algorithms.
The only prerequisites for this sequence (i.e., for CSE 221) are Math 151 "Calculus and Analytic Geometry", and CSE 201, 202, 203, or 204, or EG 167, or other evidence of prior programming experience via AP examination or the CSE placement test. These prerequisites (not including the new CSE 203 and CSE 204) have been adequate, in general. Efforts are currently in progress to examine the correlation between student performance and student preparation for CSE 221 (i.e., the means by which they met the prior programming prerequisite), which seems important because the introduction of CSE 203 and CSE 204 starting in Au07 might lead to a number of students coming into CSE 221 through these new courses.
Math 366 "Discrete Mathematical Structures I" is a corequisite for CSE 321. As far as we know, this course is meeting our needs. A new effort is underway to develop interesting courseware to connect concepts of formal logic and proof argument between CSE 321 and Math 366. A description and prototype/demo version of this software, called Syrus, is available at http://syrus.cse.ohio-state.edu. The pace of its further development depends on the availability of funding, which has been requested from both the College of Engineering and the National Science Foundation as of May 2007.
CSE 321 is a prerequisite for the various CSE 459 "Programming Languages for Programmers" courses. For most of these there is no problem. However, it has sometimes been reported by students that CSE 459.21 "Programming in C", CSE 459.22 "Programming in C++", and CSE 459.23 "Programming in Java" are assuming too little background of the students who enter that course through CSE 321. One problem here is that there is an alternate prerequisite for CSE 459.21: CSE 314 "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 CSE 459.21 from that path, it seems impossible to make the course sufficiently interesting and useful to students who have come through CSE 321. Advisors should be reminded to advise students that CSE 459.21 might not be the best choice of CSE 459's for CSE majors. Any problems with CSE 459.22 and CSE 459.23 should be coming under control now that enrollments are not so large. This has permitted the assignment of Neelam Soundarajan and Paul Sivilotti, who are rather familiar with the content of the software spine courses, to teach CSE 459.22 and CSE 459.23 this year and/or next. They will be able to make sure that these courses build more directly on the background of students coming out of CSE 321. Still, qualitatively different languages such as LISP and Perl might be better CSE 459 choices to broaden students' language backgrounds.
CSE 321 is also a prerequisite to CSE 560 "Systems Software Design, Development, and Documentation", which is seen from a prerequisite chart to be the keystone course in the entire CSE program. In CSE 560, students work in groups of 4-5 people on 2-3 fairly large systems-programming projects. They may use any language they wish for these projects. In particular, they need not use Resolve/C++. Indeed, most students try to learn an "industrial-strength language" during CSE 560, such as Java or C#, or they try to use C++ without any particular discipline. A major development on this front is the proposal from Paul Sivilotti to introduce a new course CSE 494J "Software Development in Java", which has been approved for piloting in Au07 and Sp08. Once this is in place as a course that builds explicitly on the concepts in the software spine and serves as a prerequisite to CSE 560, it is anticipated that most groups will be using Java for the CSE 560 project.
Apparently there are no issues in terms of prerequisite fulfillment for
the other course that directly requires CSE 321, namely CSE 625 "Introduction
to Automata and Formal Languages".
The software spine courses play a key role in meeting the ABET Criterion 3 and CSE program outcomes.
In all three courses, students are required to demonstrate proficiency in the areas of software design and development and algorithms, and to apply these principles and practices to a variety of problems. 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 CSE 221.
In all three courses, but especially in CSE 321, students must demonstrate proficiency in relevant aspects of mathematics, including discrete mathematics. They learn to read and to use formal specifications starting in CSE 221. These specifications involve several discrete math theories -- sets, strings, functions and relations, graphs -- and, in CSE 321, regular and context-free grammars and languages.
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 CSE 321 project, we give students the opportunity to develop their abilities to work with others in both classroom and laboratory environments and to develop their communication skills. 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 by assigning readings in CSE 221 that relate to a variety of contemporary issues that change from term to term, e.g., licensing of software engineers and 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 and their preparation for graduate study. CSE 222 involves three assignments that require students to learn some intermediate HTML, e.g., tables, on their own, thereby contributing to students appreciating the need for life-long learning.
Under the current ABET Criterion 3 -- to which the CSE program outomces are closely aligned -- engineering programs must demonstrate that their students attain:
This group of courses strongly contributes toward meeting 3c and 3k; moderately toward criteria 3a, 3d, 3e, and 3g; and to a limited extent toward criteria 3b, 3f, and 3i. 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. There is also a closed lab on hashing in which the empirical results of hashing various sets of data are observed and compared to analytical results based on the law of large numbers.
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, most of 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 the ABET
Criterion 3 and CSE outcomes are summarized in the following table:
| CSE Course | ABET 3a |
ABET 3b |
ABET 3c |
ABET 3d |
ABET 3e |
ABET 3f |
ABET 3g |
ABET 3h |
ABET 3i |
ABET 3j |
ABET 3k |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 221 | XX | X | XXX | XX | XX | X | XX | X | XXX | ||
| 222 | XX | X | XXX | X | XX | X | X | X | XXX | ||
| 321 | XX | X | XX | XX | XX | X | X | X | XXX |
Concern: "We recommend [with respect to CSE 459.22] making
the prerequisite just CSE 321 (without CSE 459.21), and beefing up the course
to take advantage of the fact that students coming out of CSE 321 already know
a good deal about C++. CSE 459.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."
Response:
CSE 459.21 (i.e., C) was removed as a prerequisite to CSE 459.22 (i.e., C++). Other steps outlined in Section 2.2 also have been undertaken to address this concern.
Concern: "Despite the prior programming prerequisite for CSE 221,
two problems mentioned in Section 1 that we hoped to address -- boredom for
relatively advanced students in CSE 221, and a significant 'intimidation factor'
-- remain problem areas. There is still an astonishingly wide range
of backgrounds and abilities represented in CSE 221."
Response:
A wide gap remains in student background and abilities, with resulting cases
of boredom and intimidation. This problem is not unique to OSU's CS1.
Even so, progress has been made. The activity-based, cooperative-learning
format of CSE 221 (see next section) allows advanced students to take an
active role in helping along students with less background in CS, thus reducing
their boredom. Also, the sense of "learning community" associated
with cooperative learning helps to reduce the intimidation factor. However,
as stated in the previous two reports, "we continue to seek ways to address the wide
spectrum of student backgrounds more effectively".
Concern: "Students in the CSE 221/222/321 sequence are required to adhere to a well-developed discipline for software design and development. Programs that result from following this discipline differ from traditional C++ programs. As a result, some students experience difficulty transitioning to the world of 'normal' C++ programming. We need to find ways to smooth this transition for the students."
Response:
The steps outlined in Section 2.2 regarding CSE 459s, and the new CSE 494J, should help address this concern. Their impacts should be known by the time of the next report on this course group.
Concern: "We would like to integrate more current topics of interest into the sequence. In several instances, we believe this will be easy to do. For example, we would like to introduce XML in connection with our coverage of context-free languages. Some of the programming assignments in CSE 222 provide good opportunities for students to write and use CGI scripts. The larger project in CSE 321 can be used to introduce students to socket programming."
Response:
The problem with writing actual CGI scripts is that the computing staff are reluctant to have students doing this on network-connected machines because of security risks. We have not pursued a stand-alone lab for such assignments, but if one were available for other purposes we might be able to leverage it. A review and possible revamping of the major CSE 321 project currently is being considered, and it might be able to consider an introduction to XML as part of it. In CSE H222, the rudiments of "socket programming" via higher-level Character_IStream and Character_OStream objects have been introduced during the past couple years. It might be possible to introduce one hour of this discussion and experimentation into all sections of CSE 222 with a slight overhaul of the schedule. This will be considered over the next academic year as other incremental changes to the software spine are being made.
Changes to Resolve/C++:: Concerns had been voiced by students and by faculty teaching CSE 560 and CSE 630, where some students use Resolve/C++, indicating that students were having difficulty designing their own Resolve/C++ components. Apparently the problems were both with designing their own interface contracts and with completing implementations of them. Regarding the former issue, we knew from the beginning of the Resolve/C++ version of the software spine courses that there was not enough time to do a credible job of teaching students how to design new component interfaces; the course intended learning outcomes have never included this capability. However, regarding the latter issue, one of the problems that could be addressed was that the file structure of Resolve/C++ components was a practical impediment to student success. This led to a number of changes to the Resolve/C++ discipline and existing components, and updates to the associated course materials as of Su06. Among other things, the file structure of a component was dramatically simplified. This permits things to go more smoothly in CSE 222 and CSE 321. There is no evidence yet that it dramatically impacts students' ability to design their own components after CSE 321. It might be too soon after this change to tell whether there is any downstream impact, and/or it might be that the real problem is actually the one we knew of all along: students in the software spine courses do not practice designing their own components, so they can hardly be expected to have become comfortable doing it. This is worth watching over the next few years.
Elimination of CSE H221: As overall CSE/CIS enrollments decreased and the GPA for admission to the programs fell back to 2.0, the number of honors students fell significantly. CSE H221 and CSE H222 had experienced enrollments on the order of 35 students in peak years -- to the point where special permission from Honors and Scholars was required to allow all comers to enroll. Recently, CSE H221 enrollments had dropped into the low teens. Partly to offset the additional cost to the department to teach new honors versions of CSE 625 and CSE 680, it was agreed that CSE H221 could be discontinued. CSE H222 remains intact, with enrollments in the mid-teens recently. It is easier to recruit students into CSE H222 because the candidates typically are in CSE 221 the quarter before; in contrast, it was difficult to recruit students into CSE H221 because of the variety of prerequisite paths and because often there is a hiatus between the prerequisite courses and CSE 221. CSE H222 seems to be working well.
Continued studies of the new approach to teaching pointers in CSE 222: All pointer manipulations for Resolve/C++ programs are now monitored at run-time by contract-checking components that immediately detect and report all pointer contract violations: dereferencing a null or dead ("dangling") pointer, deleting a dead pointer, or creating a storage leak. Before checked pointers, some students used to spend countless hours debugging "segmentation fault" and "bus error" messages. There seems to be much less of this now, judging by the number of students complaining about these lab assignments and by the number of office visits to solve such problems. The checked-pointers work has been described in a SIGCSE paper (available from the CSE 221/222/321 home page). Undergraduate student research projects continue to explore the impact of using checked pointers in CSE 222.
Monitoring precondition violations: Au04 brought a new investigation that leveraged some unique capabilities of contract-checking components. All the components used in this course sequence -- including the built-in Resolve/C++ types such as Integer and Text as well as pointers -- automatically detect component contract violations by the client and immediately report them to the programmer. For example, if a student divides by zero, tries to pop from an empty stack, etc., there is a contract violation: the precondition of the operation was violated at the point of the call. From Au04 (continuing only through Su07), we have been logging all such violations for off-line analysis. This project combined software engineering and education research. One objective was to analyze the classes of errors students make in using carefully-specified components; for the research aspect, we had an approved human-subjects protocol from the OSU IRB. A more immediate pedagogical objective was to identify quickly students who are making many errors on a lab assignment, or who are continually making the same kinds of errors, in order to intervene long before the assignment could be graded and returned. Because of barriers that the OSU IRB insisted on erecting if we wanted to continue this project as a research enterprise -- and that would have made collecting data an administrative nightmare -- during the past year we simply treated the monitoring and logging of precondition violations as a standard part of the Resolve/C++ environment. In principle, data from logs could be used for instructional improvements as deemed appropriate by this course group. So far, log data have been used to provide limited feedback to entire classes of students but not to individuals. The group found no apparent benefit to students from doing this and decided to suspend logging beginning in Au07.
Will CSE 321 be reduced by 1 cr-hr?: If CSE 494J works as planned, then it is likely that we will need to reduce CSE 321 by 1 cr-hr. The group is working on how to accommodate this by jettisoning some material from CSE 221 and CSE 222, by moving some material (e.g., BSTs) from CSE 321 into CSE 222 and some from CSE 222 to CSE 221, and by adjusting the CSE 321 project.
Lessons from POCAT: One of the continuing mysteries of the POCAT results involves a question about the performance of binary search trees. Since this topic is introduced in CSE 321, we still need to figure out a way to make sure students understand the differences between worst-case and average-case performance of BSTs.
| Course | Coordinator | Recent Instructors |
|---|---|---|
|
|
Long | Heym, Long, Mathias; various GTAs |
| 222 | Weide | Bucci, Heym, Mathias, Weide; various GTAs |
| 321 | Long | Bucci, Heym, Long |
People involved in preparing report: Paolo Bucci, Wayne Heym, Tim Long, David Mathias, Bruce Weide.
Date of report: May 2007