CS 210 - Lab 10: Utopia U -- Idealizing the Registration Process
Part 1 due December 11, 1997
Part 2 due December 15

General Lab Goals

This lab provides an opportunity for the class to collaboratively design and implement an idealized registration process. It also provides an opportunity to design a realistic computing application using Java and the data structures we have studied in this course. The data to be used in this lab is actual Bowdoin registration and course data for the Spring 1998 semester.

This lab will serve as part of the final exam for the course. It has a collaborative part and an individual part, which are explained below. All software and data files for this lab are in the CS210 (Tucker) -> Lab 10 folder.

Overview:

The picture in Figure 1 shows a general view of the registration process. The "Scheduler" has two major input files, the class schedule and the students' registration cards. The output of the Scheduler has three major parts, class lists (which are distributed to instructors), student schedules (which are distributed to students), and printed statistics, which summarize the results of the scheduling process. For the purposes of this exercise, we will skip the process of generating class lists and student schedules. We will focus on the registering of students in courses and the generation of statistics, as explained below.

The files classes.data and cards.data represent the input to the Spring 1998 registration process; they are provided in the Lab 10 folder for your use.

The file classes.data contains one line of text for each course section that is offered in Spring 1998. For simplicity, it excludes lab sections. A sample of the first few lines in this file is shown in Figure 1.

Figure 1. First few lines of the "classes.data" file

Each line in this file contains information about a specific course -- its department, course number, scheduled meeting time, and capacity (maximum enrollment). Some lines continue with an equals sign (=) and another course number, indicating a course that is the same as this course. Most lines continue with the title of the course and the name of the instructor (which is not useful information for this exercise).

Below is the beginning of a class definition for a single course in this file.

The file cards.data contains one line of text for each student who is registering for courses in Spring 1998. For simplicity, it also excludes lab preferences. A sample of the first few lines in this file is shown below. Figure 2 shows a sample of the first few lines in this file.

Figure 2. First few lines of the "cards.data" file.

Each line in this file contains information about a specific student -- a student id number (not the real one, of course), class, number of courses desired (listed on the first line of the registration card), total number of courses listed, and the course numbers of all the courses listed (in order of preference, reading left-to-right across the first line of the registration card, then the second, and then the third). For example, the first line shows that student #1, class of '90, wanted four courses and listed 6 courses on the card. That student's first line of choices are CHEM 226A, ES 216, BIO 272, and SOC 215; courses ES 391 and BIO 214 were listed as alternates on the second line.

Below is the beginning of a class definition of the Student class that can be used to read lines from this file. The names of the fields in this class correspond with the information on each line of Figure 2, from left to right. Since a student can list a variable number of course choices, these are most conveniently defined in a Vector.

Finally, it is important to think about the basic algorithm for determining how courses are selected for a student. That is, each course listed in the student_choices Vector must be searched in a data structure that contains the information about all courses (that data structure should be loaded from the file classes.data before this algorithm can begin). Once that course is found, two criteria must be met before that student can be enrolled in that class:

  1. That course must not be full to capacity (that is, the field enrollment, which keeps track of the number of students already enrolled in that course, must be updated each time a new student is added to the course), and
  2. That course's meeting time must not be in conflict with the meeting time of any course in which the student is already enrolled.

The first criterion is easy to check. The second criterion can be checked by keeping a list of all the possible meeting times, and along with each one a list of all times that are in conflict with that time. Below is a partial list of these meeting times and their respective conflicting times; their interpretation should be self-explanatory.

A complete list of all class meeting times alongside all conflicting times, is given in the file times.data. Below is a list of the first few lines in that file.

Here, the first line says that the time MWF8 conflicts with the time M-F8, while the third line says that the time MWF9 conflicts with each of the times MW915, MW9, and MW930.

Finally, the program should produce an output that has the information shown below.

In addition to the summary enrollment data for each course, the program should keep track of and display additional "Summary Statistics" and "Run Time Statistics."

The summary statistics reveals how many students did and did not get their desired number of courses, the number of times students were rejected from courses for time conflicts, and the number of times students were rejected from courses because the course was full.

The run time statistics reveal how much time it took to run the two major parts of your program, the loading of the class data structure and the registering of students. These numbers, of course, will vary depending on your choice of data structure and search strategy for registering students.

To assist you with this task, the skeleton program Register.java is provided in the Lab 10 folder. It simply reads records from the classes.data file into a Vector, and then reads individual student records one-by-one. It contains the beginnings of a class definition for a student (called Student) and a course (called Course). Each of these classes is a Comparable class, with predefined lessThan and equals methods provided. You may need to take advantage of that feature when you think about choosing an appropriate data structure for storing the classes.data file.

To exercise this program, set up a project that looks like this:

Now drag the files "classes.data," "cards.data," and "Register.java" into this project's folder, and then Make and Run it. Its output should be similar to that shown in Figures 1 and 2.

Major Lab Tasks

This lab has several major tasks.

  1. Design of an efficient data structure for storing the classes.data file (a Vector is the worst possible choice), and flushing out the overall structure of the program.
  2. Addition of appropriate variables and calls to track the run time statistics for the two major parts of the program (this material can be found in earlier labs).
  3. Determining, for a given student and course, whether that course's time is in conflict with any other courses which the student has been assigned so far.
  4. Registering a single student with the number of courses he/she desires.
  5. Keeping track of the appropriate summary statistics
  6. Displaying the registration results, summary statistics, and run time statistics after all the student cards have been processed.

Part 1 Outcome (Team): to develop a complete running Java program. You should prepare to demonstrate your results on December 11 at 2:00 (this is the regularly scheduled final exam time).

Part 2 Outcome (Individually): to hand in the following written work by December 15 at 5pm:

  1. A brief description of your overall role in the project, including what you contributed, what help you gave or received from other team members.
  2. A complete listing of the program that your team developed, with the parts you developed circled.
  3. A calculation of the theoretical complexity of this program, taking into account all data structures used, methods called, and the number of steps required to run each part of the program. This should be expressed in the form O(t), where t is an expression involving at least the following variables:

Organization:

By now, it's clear that this is a team project! The following three different teams are suggested, which will enable you to develop three different strategies for solving this problem. Team captains are indicated with asterisks (*), and will assign tasks and oversee the completion of Part 1.

Team A: Jon Ahn, Anne Bradley, Ryan Giles, *Seth McClead, Tom Ringle, Jonathan Wilson

Team B: Dave Anderson, Pete Caron, Matt Henson, *Dave McWhinney, Scott Roman, Joey Wu

Team C: *Lauren Bernheim, Eric Forbell, Chris Lee, Mike Nicholson, Steven Sheldon

There's a modest amount of competition involved here, since each team will want to design the most efficient registration program. That, of course, depends critically on your choice of data structures. The team that designs the most efficient (correct) registration program will win a prize at the demonstration session on December 11.