The implementation and design team whose job it is to create the Scheduler system has a great deal of work ahead of it. The most difficult part of the process will be designing the algorithm, CreateSchedule, that takes all of the information in the databases and project and generates the schedule. The most involved and time-consuming section will probably be dealing with scheduling conflicts and how the user and application interact to fix them.
The following is an executive summary of each major object and operation defined in the scheduler formal specifications.
ProjectDB is the object that encapsulates one entire project. The major considerations for its design are what format is best to store all the database information in, what parts of a project need to be stored on the disk, and which can rest in user preference files or can be recalculated upon opening the project. When a project is created and databases added to it, the Reconcile operation defines the local, project-specific databases. These are drawn from permanent global databases in the system. This will consist mostly of database operations used to copy each element.
Object Schedule is simply a list of affiliated section objects. It may be designed as a simple collection object or list, but must be sortable in a variety of ways. List operations like AddSection() are elementary. CreateSchedule() is where the above-mentioned difficulty will lie. It must assign all sections an appropriate time slot, instructor, and room while following guidelines set down in instructor preferences, locked section data, previous schedules, course requirements, room contents, and, ideally, student input. It must flag conflicts, generate warnings, judge alternatives if the best-case scenario is not available, and decide between equally-desirable possibilities. A multi-pass compiler design comes to mind. A possible approach is to first decide how items in each category are prioritized. Next the algorithm should create and sort lists of rooms, classes, courses, and instructors for iteration purposes. Next it would pick the first, for example, instructor (the one with the highest priority) and assign his or her courses to time slots that are highly preferred. It would iterate through the list of instructors so, leaving out any assignments that may cause conflicts. It would then do the same for the remaining unassigned rooms and courses. This would be first pass. On subsequent passes the algorithm might compromise higher-priority preferences in favor of eliminating conflicts with lower-priority ones. The algorithm might perform optimizing passes until there are few or zero discernable changes being made.
An Instructor, one of the primary objects of importance to the scheduling process, is a simple representational model of a faculty member who has characteristics (WTUs, name, seniority, etc) and preferences (course and time). There is also an associated "mini" schedule that contains the courses, in full detail, that the represented instructor will be teaching in the current schedule. TimePref and CoursePref objects are slightly more complex lists of name-value pairs (time + rating and course + rating). The InstructorDB is a basic database that contains all the instructor objects. Database-access operations like CreateInstructor and AddInstructor will be elementary.
CourseDB is a basic database of Course objects. A Course object is a description of a single catalog course, and contains its length in hours, number of units, department, course number, and number of sections. It also keeps track of conflicts that it is involved in. Database access operations like AddCourse and object-modification operations like AddCourseConflict will be elementary.
Similarly, RoomDB is a basic database of Room objects. A Room object is a description of a single classroom. It has information about its location, capacity, and equipment (such as computers, projectors, networks, circuit analyzers, etc.). Database-access operations like AddRoom will be elementary.
StudentDB is a basic database of StudentRecords. It also contains a ReportView object that is a list of compiled student statistics. Each StudentRecord basically contains information that students enter into a survey form. Database-access operations like AddStudent will be elementary. However, the GenerateReport operation may require complicated mathematical analysis algorithms to compile all student information into readable graphs and relevent tables of sorted data.
From a developer's standpoint, this project is challenging, and many hidden difficulties lie in the depths of some of the deceptively simple objects. The first steps that a developer should take if approaching the design of this system are: 1) Design and finalize an object hierarchy that describes exactly how each object functions, what high-level objects it relates to, and what information it contains. 2) Design each individual database and its fields. 3) Design the mathematical basis for the GenerateSchedule and GenerateReport algorithmns. 4) Implement the system and test with sample data in the approximate ranges of: 2,000 to 5,000 students, 100 instructors, 100 rooms, and 50 to 100 courses of 1 to 10 sections each.