CS 210 - Lab 9: Modeling the Student Registration Process
Due December 15, 1999
General Lab Goals
This lab provides an opportunity to design and
implement a significant piece of software that can register students
in a complete semester 's worth of courses at Bowdoin. This exercise
provides an opportunity to design a significant computing application
using Java and the data structures we have studied in this course. The
data we will use in this lab is actual Bowdoin registration and course
data for the Spring 1998 semester.
This project will serve as 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 usual
place.
Overview:
The picture in Figure 1 provides an overview of the
registration process. Your program will have three major input files;
the class schedule, the students' registration cards, and a file
listing time slots and conflicts. The output of the program would, in
practice, have 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 generation of class lists and student schedules, focussing instead
on the registering of students in courses and the generation of
enrollment statistics, as explained below.
The files classes.data and cards.data represent the
actual input to the Spring 1998 registration process.
The file classes.data contains one line of text for each
course section offered in Spring 1998. For simplicity, this file
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 with which this course is
cross-listed. The other (non-cross-listed) lines contain the course
title and the name of the instructor.
Below is the beginning of a class definition for a single course in
this file.
The file cards.data contains the information that students
fill in on their registration cards. It has 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 in Figure 2.
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, class, number of courses desired, 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.
In solving this problem, 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 array 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:
-
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
-
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 conflicts.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 MWF9 conflicts with each of the three 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 reveal 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.
Scheduling Algorithm
Essentially you will make successive passes on the students. Starting
with the seniors and working towards the first-years, to register a
student for a course you look at the student's next choice, check if
the course is full, then check if the course conflicts with a course
they are already registered for. If the course is ok, the student
gets it. Remember, a student shouldn't get more courses than they
ask for.
Major Lab Tasks
The work for this lab can be divided into several major tasks.
- Design classes for students, courses, and conflicts. These
should all be straightforward. There should be variables to
store the relevant data for each structure, and access methods
for setting and retrieving data. Ultimately, you will include
each of these in a larger data structure (e.g. a Vector of
students, etc.).
- Design methods to read in all of the files.
-
Design efficient data structures for storage, and flush out the
overall structure of the program.
-
The data structure choices here are Vector, List, Stack, Queue, Binary
SearchTree, AVL Tree, and HashTable.
-
Each choice presents performance tradeoffs for adding elements during the
building phase and searching the data structure to find elements during
the registration process.
-
Remember, to register 1400 students with 4 choices per student requires
5600 separate searches in this data structure!
-
Inclusion of appropriate variables and calls to track the run time
statistics for the two major parts of the program.
-
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.
-
Registering a single student with the number of courses he/she desires.
-
Keeping track of the appropriate summary statistics
-
Displaying the registration results, summary statistics, and run time
statistics after all the student cards have been processed.
Part 1: a complete, correctly-running, and well-documented
Java program for this problem.
Part 2: the following hardcopy, which
is due on December 15 at 5pm:
-
A brief description of your overall role in the project, including
what you contributed, what help you gave or received from the other
team member (if you worked in a pair).
-
A complete listing of the program that your team developed, with the parts
you developed circled.
-
A discussion of which data structure your team settled upon and why you
made that choice.
Organization:
Thisproject may be done in groups of two. However, you may not
work with someone that you worked with on a previous lab.