This project involves the design and implementation of a simple, computerized Student Scheduling Assistant to aid undergraduate students in selecting their courses.
An undergraduate student at the University of Toronto has to solve a difficult constraint and scheduling problem every time she or he registers for courses. Constraints arise from the prerequisites that exist for some courses (e.g. a student must take CSC340H before they can take CSC408H). Scheduling difficulties arise because the lecture/tutorial times for two courses may overlap, making it impossible (we assume) to legally take both courses.
Course Key The course key is an identifier for a course. The 9-character course key has the form DDDNNNLCW where
Prerequisite Key A prerequisite course key is a 7-character prefix of a course key. It has the form DDDNNNL (as defined above). This indicates that the session and campus where the student takes the course are irrelevant to determining whether the prerequisite has been satisfied.
Course Data Base The course data base contains the describes all of the courses that are available for a student to enroll in. The course data base describes the courses for some period of time. (typically the Fall and Winter sessions).
Course Description A description of a course in the course data base includes (at least): a) a 9-character course key. (e.g. CSC408H1F ) b) the official name for the course (e.g. "Software Engineering") c) a list of the days and times for lectures in the course (e.g. Monday 11-12, Wednesday 11-12). There may be several lectures a week for a given course. d) a list of the days and times for the tutorials in the course (e.g. Friday 11-12). There may be more than one tutorial a week for a given course (e.g for a foreign language course). e) a list of Prerequisites for the course. Prerequisites are described as a list of prerequisite course keys. A student must have taken ALL of the prerequisites BEFORE they can legally take this course. The representation of the Course Data Base is a matter of design to be determined by each implementation.
Student's Data Base A student data bases is an individual student's record of the courses he or she has taken (the Taken List) and the courses that she or he wishes to take (the Want List).
Taken List A list of course keys for the courses that the student has taken.
Want List A list of course keys for the courses that the student wants to take in the next academic year. The representation of a students personal data base is a matter of design to be determined by each implementation.
The Student Scheduling Assistant software should implement reasonable default actions in order to provide a convenient and simple interface to its users. For example, automatic creation of a data base if one does not exist when the program is invoked. Default names for data base files if none are provided by the user. The software should check for illogical and ill-defined actions and emit warning and error messages as appropriate. For example, adding something that already exists or removing something that isn't there.
The internal representation of the Course Data Base and the Student
Data Base (taken and want lists) is to be determined by each
implementation. Each of these data bases should be able to be specified
as a name within the Unix file system name space. The interpretation of
this name (i.e. as a directory or a file) is par t of the design of each
implementation.
The default name for the Course Data Base is CoursesDB. The default name
for the Student Data Base is MyCoursesDB.
The default location for these data bases is the directory in which the
program is executed.
The executable program for the Student Scheduling Assistant will be named ssa. The program will be invoked as
Where the options are optional flags that modify the behavior of the program. All implementations should support the options listed below. Other options (i.e. non-standard options) may be provided by an implementation.
The program will (unless redirected) take its input from Unix standard input and produce its output on Unix standard output. Error messages for users should appear on standard output. Error messages indicating internal or operational problems should appear on Unix standard error.
Time is represented using a 24-hour clock. The values for times run
from 00:00 to 23:59. The minutes part and the preceeding colon can be
omitted (.e.g. 15 means 15:00). The time for a lecture or tutorial is
given as a time range consisting of a star t time optional white space,
a hyphen, optional white space and an end time.
Examples: 11 - 12 11:00 -12:00
Days are represented be their ordinary English names (e.g. Monday,
Tuesday, Wednesday ) or by any unique prefix of these names (e.g. Monday
could be Mon or Mo or M). We resolve the ambiguity that this convention
introduces by defining T as the name for Tuesday and allowing R as a
1-character name for Thursday. Saturday and Sunday (which occur rarely)
do not have single character names. Days and times in a list of lecture
or tutorial times are represented as dayname whitespace time range.
Examples Mon 11-12 R 10 -10:30
A lectureList or tutorialList consists of a comma separated list of
lecture or tutorial times.
For example M 11-12,W 11-12 Mon 11 - 12 , Wed 11:00-12:00
The format for the 9-character course key ( DDDNNNLCW ) and
the 7-character prerequisite key ( DDDNNNL ) have been defined in the
original software handout. The prerequisite list used in the ADDPRE
command (see below) is a list of prerequisite keys separated by commas.
For example csc340h , csc378h
In this section we specify the exact form of the arguments to the
various commands. The dbname is an optional argument. If it is omitted,
the current course or student data base is used other wise dbname
becomes the new current data base. The ADD command is described in the
following section.
| Command | Argument | Command | Argument | Command | Argument |
| COURSE | coursekey | QUIT | UNTAKEN | coursekey | |
| DELETE | coursekey | SAVE | dbname | UNWANT | coursekey |
| LIST | SHOW | WANT | coursekey | ||
| LOAD | dbname | TAKEN | coursekey |
The ADD command is a special complicated case since it has to provide
all of the information required to completely specify a course
description.
To simplify the preparation of input for the program and to allow easier
testing of the program, the ADD command is hereby split into four
independent sub-commands
| Comannd | Arguments | |
| ADD | coursekey | courseName |
| ADDLECT | coursekey | lectureList |
| ADDTUT | coursekey | tutorialList |
| ADDPRE | coursekey | prereqList |
Where
QUIT should implement a simple query to stdout. Something like:
It can be assumed that the response will be
If the response is neither of these, N is assumed and quit.
Do NOT repeat the Query.
This query should only happen if there are changes that have not been saved. i.e the sequence
Should not get a Query.
There is no need for any special password/permission mechanism to allow a person to function in admin mode. The only requirement is that they have write access to the course data base.
The Student's Database has also no protection. Different stundents are using different student databases.
SSA should work on the Linux workstations presently installed at CDF. There is no requirement to suppor t any other kind of use.
It is assumed that at any point in time at most one administrator is ever trying to modify the course data base and that while the course data base is being modified, no student will try to use it. it is also assumed that each student data base is modified only by the individual student who owns it.
SSA should follow the standard Unix conventions for input and output. Input comes from standard input (stdin), output is directed to standard output (stdout), error messages may be directed to standard output or standard error (stderr) depending on the nature of the message. The intent of this convention is to make it convenient to use the program interactively or with input from a file for testing.