| 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 into what information people really need from the system and to what exceptions might exist in the data. Some of the most successful projects I've worked on started from defining the reports that people needed to see and then defining the systems needed to collect that data. It might be worth thinking about: whether a system is information-centric as opposed to action-centric." |
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. PLAN GLOBALLY, DEVELOP LOCALLY Incremental implementations should fit into a global plan. |
HIKING THE APPALACHIAN TRAIL The Appalachian Trail stretches for 2,148 miles, more or less. A hiker typically walks 10 to 15 miles a day, so hiking the entire trail usually takes about five or six months. Some hikers finish it in an unbroken journey. Others, like me, complete it in sections. A map of the entire trail from Georgia to Maine aids in long-range planning. It helps if you determine roughly the amount of time required to finish each section. The full trail map is useless for day-to-day planning, but it gives the context for daily hikes. Each daily hike occurs in the context of resupply points. You cannot carry more than a 7-to 10-day supply of food. If you plan your resupply points carefully , you can carry less food ”as little as three or four days' worth. Carrying less weight is always better. Section maps provide more detail on a 50- to 70-mile length of trail. You plan your daily hikes with section maps: where you will eat lunch and where you will spend the night. Your daily hike plan takes into account not only the trail itself ( flatness or steepness), but also the weather (rainy or cold) and your own personal health (fatigue or sickness). Each daily hike advances you to the goal of becoming a 2000-Miler , the term for a hiker who has completed the trail. You cannot plan every day on the trail in advance. You cannot forecast what the weather or your own personal health might be in the future. But your day's hike fits into the overall goal. You walk for the day, but you keep looking forward to tomorrow. |
|
