Prefactoring: Extreme Abstraction, Extreme Separation, Extreme Readability
| < Day Day Up > |
| 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.
Charge_CDDisc a nd Provide_discounts revolve around how a rental is priced and paid for. They are an extension of Sam's current system. They are further down in the list of features to add. We know they will affect the current classes, since the classes do create a customer contract. If Sam wanted these features to be implemented as soon as the baseline system was created, Tim and I would explore them more fully before proceeding with the design. At this point, we need to replace his manual system first, and later we can get further into the rental policy details.
|
| < Day Day Up > |