Jane Chu Prey
Department of Computer Science
Thornton Hall
University of Virginia
Charlottesville, VA 22903
email: prey@cs.virginia.edu
The University of Virginia began an ambitious undergraduate computer science curriculum revision in 1992. One of the cornerstones of our new curriculum is the use of cooperative learning. We use the cooperative learning model in closed laboratory activities developed for the first four core courses. This paper discusses how we have incorporated a cooperative learning environment into our new curriculum. An example of the cooperative learning activities from the CS1 course is given. (Others are available upon request.) We believe we have developed a cooperative learning environment which serves our students well as they continue their education here and in the working world.
As computer science grows as a discipline, undergraduate computer science education continues to change and, has for the most part, kept pace with the new topics in the field. However, the pedagogy has not changed significantly. At the University of Virginia, we had a traditional undergraduate curriculum with the traditional lecture approach. Curricula like ours emphasize:
Comparing the content of the curriculum with the situation in the real world, we see a considerable contrast. Practicing computer scientists deal with the antithesis of what we teach:
This list illustrates the general range of skills needed by a contemporary computing professional. This set of skills is the antithesis of what we are teaching. Clearly, there is a serious mismatch between what is taught, how it is taught, and the emphasis it receives on one hand, and what the consumers of the education actually need on the other.
Our new curriculum is driven by the desire to make the necessary changes to accommodate the educational needs of the future computing professional. These changes necessitate a complete revision of the content, approach, and resources used in the undergraduate teaching program.
We believe that a change in pedagogy provides the highest leverage for improving computer science education. We began an ambitious undergraduate computer science curriculum revision in 1992. One of the cornerstones of our new curriculum is the use of closed laboratories to facilitate cooperative learning.
To address the need for students to learn to work with each other, we have adopted a ``closed laboratory'' component for the first four courses in the new curriculum. In the closed laboratory, interaction between students is encouraged while instructors are present to facilitate. Students are given problems and activities to complete within the closed laboratory session. One of the goals of the closed laboratory is to provide an opportunity for students to make mistakes, to try different options without serious consequences. They are encouraged to ask each other questions before asking the instructor. All students are challenged to explain the concept or problem to other students, presenting their own perspectives. All students have many opportunities to be the active/teaching partner throughout the semester.
There are also more formal group activities in the lab. Students are randomly assigned to groups to work together on the activity. These activities are generally more complex than ones students can do individually. It requires the group to work together to solve the problem or complete the activity. Some of these activities may involve work outside the laboratory and require several weeks of coordinated work within the team.
Since we begin group activities and cooperative learning in the first course and continue using it in the next courses, students develop an understanding of the importance of working with others; they learn how to deal with things other than the technical components of a situation. Because we expect students to work together in the first course and continue this model through the next three courses, we find that students understand and appreciate the experience - they ``buy into'' the idea of working together and helping each other.
We have attached an example of a closed lab activity from our CS1 course. Working through the activity will give the reader a sense of the interaction and collaboration, the experience we are trying to provide the students.
The next three courses continue to use the cooperative learning with the closed lab activity. The labs for the following courses depend more heavily on the cooperative learning model; they are designed to be less structured and to promote more interaction within larger groups. We offered the fourth course of the curriculum (Advanced Software Development) for the first time this Spring semester. It is a semester long project course with groups of 6 randomly assigned students working together for the entire semester to produce a product and all of its related documentation. Students were expected to plan together, to work together, to demonstrate a maturity expected in the working world. We were not disappointed! At the end of the semester, every group had a demonstrable product and appropriate documentation.
Problems of a group of people working together did occur; students handled it within the groups. We were told about the problems, asked for advice on how to deal with them but not asked to intercede. Without the extensive cooperative learning experience, these students could not have completed the level of the work demanded in this course. We would have spent significantly more time dealing with the concept of group work. The students would not have learned as much about software development nor experienced something so similar to the working world.
Working with other students in the lab was...
The closed laboratory cooperative learning experience has been very popular with both students and faculty. Student evaluations indicate high levels of satisfaction from the laboratory sessions both from an academic perspective and an interpersonal perspective. Students enjoy helping each other without realizing they are reinforcing their own skills and knowledge in the process. Faculty responses are equally enthusiastic. Both students and faculty believe students are learning more material and learning it better.
Reboot your computer before the start of this lab.
You will not need to copy any files to your floppy disk to complete this lab.
To date, the largest program we have worked with is only 800 lines long. A real software system can easily contain tens of thousands, hundreds of thousand, or millions of lines of code. In this lab, we will examine a program of moderate size and consider some of the practical issues involved in dealing with the design, implementation, and maintenance of a large software system.
The program we will examine is called fractint. It is a program that calculates and draws fractals on IBM PC graphics hardware. At 60,000 lines, fractint is only about a tenth as big as a typical inventory control system, but it is large enough to demonstrate some of the issues of software complexity.
Before we examine the source code to fractint, we will want to see what the program does and how it runs. Fractint is a DOS Program, and we will not be using Microsoft Windows to build or to run it.
Now that we have seen fractint run, we will compile the 60,000 lines of fractint source. These lines would be unmanageable. These source files are held together with a Project File called fractint.prj. Basically, fractint.prj is a list of all the source files that must be compiled in order to build fractint.exe.
Your floppy disk is too small and to slow to compile fractint, so we will use the hard disk.
Now, we'll take a closer look at the fractint source. Your current line number in a source file can be found in the lower left corner of the Borland C++ for DOS edit window. Or, if you choose to use Borland C++ for Windows to examine the Fractint Source, you may find that the ``Go to Line Number'' option in the File menu will be helpful.
Now that we've had a chance to work with a large program, the teaching assistants will lead a discussion on our activities. In this discussion, you might want to consider any problems you had answering the fractint questions, and you might try to suggest what might have been done differently in fractint to make your job easier. If you can think of any documentation that might have helped you, or if you can think of any tools that could have made your job easier, identify them in the discussion. Also, you might consider your answers to the pre-lab survey in the light of your fractint experience.
All the files you need to run fractint are in frain17.zip. This .zip file can be obtained by ftp from the \public_access directory of virginia.edu.
A more recent version of fractint can be obtained by anonymous ftp to the site oak.oakland.edu. This .zip file can be obtained by ftp from the \pub\msdos\graphics and it is frain182.zip.
If you need help in retrieving or unpacking these files, see the instructions in Lab 6. These instructions will work from ITC microcomputers as well as from Olsson 001.