Prefactoring

4.4. Global Planning, Local Designing

You might be concerned that Tim and I are ignoring the other use cases. While we concentrate on a few of the cases in detail, we still review the others to help guide us in the design. One cannot deal with every facet simultaneously. We might have to alter our design when we get to the details of the other requirements. The requirements might change in the future and some use cases might go away before they are implemented. However, if our design cannot perform the other use cases, we need to redo it before proceeding.

After coming up with the initial set of classes, we examine each use case to see how it might affect the class selection. From our preliminary analysis, Search_catalog appears to be a fairly separate module. This case deals mainly with the CDRelease class. The Show_availability case will use CDDisc. In both cases, we feel the basic class layout should not need to be altered, although the classes themselves might require modification.

The Report_when_CDDiscs_are_overdue case creates a report. Since Checkin_a_CDDisc already checks for overdue rentals, the required information is probably already captured. From past experience, we know that reports are typically the easiest feature to write, since data states are not being changed. Therefore, we do not believe that this case will have a heavy impact on the classes.

REPORTS CAN DEFINE THE SYSTEM Graham Oakes, a reviewer, suggests, "Reports often give the greatest insight ...