As outlined in the UI Overview, the Scheduler Tool system is comprised of three interfaces, one for each type of user. The three types of users are scheduling administrators, instructors, and students. It provides functionality to generate schedules based on information in the three databases for Instructors, Courses, and Rooms.

In the adminstrator interface, scheduling administrators have the ability to view and modify records in the databases and generate schedules for any term. The projected size of these databases is probably not big enough to require implementation using a database management system. Rather, some form of efficiently searchable collection should do. The reason this is the case is that there are no requirements for sophisticated querying against the databases, and query support is typically the most important reason to employ database management technology. It's implementation will need to provide efficient access for a wide range of operations, including serial navigation, lookup by keywords, and filtered searching.

Aside for the Schedule, the other objects in the regular user scheduler tool should have reasonably straightforward implementations. The different forms of schedule viewing will produce dynamic objects, that need not be exists in persistent storage. Rather, the views are computed from 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.

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 network support is available, dependable, and well documented.