As outlined in the UI Overview, the Scheduler Tool system is comprised of three separate application programs. The adminstrator program runs for only the Department Scheduler and requires identification for special access. It provides functionality to view and modify schedules, to maintain the databases, and connect to a central server on which published schedules are stored. The other application program is for students and instructors. It allows instructors to input their preferences about which courses they would like to teach and when, as well as allowing students to give feedback about why they were not able to get some of the classes they wanted. It provides functionality to view schedules.

In the students and instructors user application, the major object in the user program is the Schedule. It's implementation will need to provide efficient access for a wide range of operations, including navigation, lookup by quarter, year, instructor, or room number, and filtered viewing. Hence, it will need to use a moderately sophisticated data structure that supports these various forms of access. For example, it could use a hashed top-level index, with threading among hash table entries to support serial traversal.

Aside from the Scheduler, the other objects in the administrator scheduler tool should have reasonably straightforward implementations. The only tricky aspect will be the algorithm for generating schedules. This algorithm will have to take into account the day and time pattern restrictions, the amount of instructors available to teach, and the number of rooms available for lecture. These restrictions will all be incorporated in the final schedule output, as well as any instructor preferences. There will then need to be a fairness algorithm for the schedule to figure out how closely all instructor preferences are met. The different forms of schedule viewing will produce dynamic objects, that need not exist in persistent storage. Rather, the views are computed form the underlying schedule data, displayed on user demand, and then discarded. The Schedule data structure will need to provide access functions to support the different views.

In administrative application, the major objects are the five databases for Instructors, Rooms, Buildings, Courses, and Schedules. The projected size of these databases is probably not big enough to require implementation using a database management system. However, use of the databases will require sophisticated querying for scheduling purposes, so a database management is necessary. The reason this is the case is that there are requirements for sophisticated querying against the databases, and query support is typically the most important reason to employ database management technology.

The distributed processing of the networked Scheduler Tool environment will require specific development expertise. In particular, the developers need knowledge of client/server design and implementation. Functionality to support client/server architectures is available in many modern libraries. It will make sense for the developers to choose an implementation language in which client/server support is available, dependable, and well documented.