4. Summary

This document provides an executive overview of the architecture of the model.

The high level aggregate objects, Schedule and Database are found in the Schedule package. These value objects contain structures composed of the classes contained in the Instructor, Time, User, Rooms and Course packages.

Of these packages, only preferences contains objects with significant logic. All others should contain only value classes which will be mostly trivial to implement. The only major considerations will be which concrete data structures to use.

The preferences package, conversely will likely present difficulties in implementation. It is imperative that the logic in the preferences operate very quickly. This is because they will be repeatedly called to analyze a high number of candidate schedules. Each preference will have unique logic that will need to be optimized separately.

The other package with significant logic is the generator package. This will also be a challenging package to implement, as it requires complex logic and will be performance critical. It is likely that the algorithm specified will be untenable and will need to be changed. It may either be too computationally expensive, or be poor at generating schedules that are of comparable agreeableness to those created by the current manual system.

Important work will need to go into the database and file management features of this system. These items are currently unspecified and will require research into what tools and techniques will be most applicable. Of particular importance is the interoperability of the created schedules with the expected file format used University-wide at Cal Poly.

Prev: Non-Functional Requirements | Next: None | Up: Index | Top: Index