4.1. The Rest of the Story

 <  Day Day Up  >  

To understand more fully the system we are creating, we sketch out the remaining use cases. Figure 4-1 shows a graphical view of the relationships between the different cases. The following use cases are written using the abstractions that Sam, Tim, and I agreed upon:

  • Report_when_CDDiscs_are_overdue

    1. Clerk requests a report.

    2. System responds with a list of CDDiscs and a list of customers who owe overdue fees.

  • Search_catalog

    1. Customer enters search criteria (artist, song title, etc.).

    2. System responds with CDReleases matching those criteria.

    3. Customer selects a CDRelease.

    4. System responds with songs on that CDRelease.

  • Show_availability (extends Search_catalog)

    1. Customer requests availability of a CDDisc for a CDRelease (which store it is in).

    2. System responds with availability status.

  • Provide_discounts (extends Checkout_a_CDDisc)

    1. When CDDisc is rented, give a discount to frequent renters.

  • Charge_rental (extends Checkout_a_CDDisc)

    1. When CDDisc is rented, add charge to monthly bill for customers.

    2. At end of month, bill customer's charge card for total amount.

Figure 4-1. Use cases for Sam's system

For the first production release of the system, we want to ensure that we have the minimum feature set (MFS). The MFS contains the minimum set of requirements that will provide a usable program. For Sam's system, a program having a check-out feature without a check-in feature would be unusable.

 <  Day Day Up  >  


Prefactoring
Prefactoring: Extreme Abstraction, Extreme Separation, Extreme Readability
ISBN: 0596008740
EAN: 2147483647
Year: 2005
Pages: 175
Authors: Ken Pugh

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net