Report on Team #3, Video Store Problem, Sunday

Team Members

Doug Bennett (client / user)
Kevin Johnson (moderator)
Gail E. Harris (reporter)
Paul Chisholm (designer)
(designer)
(designer)
(designer)

This document reproduces the charts the team prepared for the Thursday session. It also contains some additional comments from the reporter from notes taken during the Design Fest. For background information on the problem please refer to the Problem description.

Charts prepared for Thursday

Chart #1 Problem & Process

The Problem

Produce

Chart #2 Rental Lifecycle

  1. member rents copy
  2. charged fee
  3. pays fee
  4. returns copy
  5. check if late
  6. if late charged late fee
  7. if late pays late fee

Chart #3 Final Object List

Category Store

Category Membership

Category Inventory

Category Accounting

Chart #4 Assumptions

Chart #5 Change Case Impact (1 of 2)

Please refer to the Problem Description for details about the change cases.

Case 1: Build time (for queries)
  • we would (could) want to adjust the design to make this run time only
Case 2: Build time
  • Purchase object
  • no change to Policy objects
  • add billing functions
Case 3:
  • Create UI/report
  • add to capture scanning current inventory

Chart #6 Change Case Impact (2 of 2)

Case 4: Build time
  • Active Rental if return to any store
  • Architecture (central vs. distributed)
  • add functions to maintain even distribution of copies
  • add queries of other location's inventory
  • Member - home stores, "allowed to rent from" list
Case 5:
  • LOTS more data to be captured
  • Financial Objects: Purchase, Transaction, Rental Copy
  • see Case 7

Chart #7 Deferred

Chart #8 Conclusions

CRC Cards (in no particular order)

 Active Rental

Responsibilities 

Collaborators 

due date

Member 

rental transaction 

Rental Copy 

rental date 

Store 

late transaction 

Transaction (many to many) 

rewind fee transaction 

damage/replace transaction 

Transaction (a.k.a. Atomic Transaction)

Responsibilities 

Collaborators 

record price 

Policy 

adjust due date 

Rental Copy

Responsibilities 

Collaborators 

checked out status 

Active Rental

ID (Bar Code) 

Rental Item 

Home store 

Current Store

Purchase Date 

Purchase Cost 

Rental Item (may have multiple copies of each item)  

Responsibilities 

Collaborators 

Maintain product information

Rental Copy 

status (reserved) 

query support 

list of copies 

policy information (base policy)

Shelf Product
(possibly only required with store where actual video cassettes are stored behind the counter)

Responsibilities 

Collaborators 

can get to a rental copy 

(none recorded)

Member

Responsibilities 

Collaborators 

cancel, cancelled status

Active Rental 

address 

Transaction

phone number 

Contact Track

credit information

Policy

names

member ID

print card

policy (who can rent what) ratings history

find transactions

find active rentals

(category)

(home store ?) 

Contact Track

Responsibilities 

Collaborators 

Call Member re. Transactions and Active Rentals

Member

Active Rental

Transaction

Policy

Responsibilities 

Collaborators 

Calculate price and due date

Purchase

Do I apply

Transaction

Refuse Rental 

Can I be combined

Historical Rental

Responsibilities 

Collaborators 

Returned date

Member

Rental date

Rental Item

original due date

Rental Copy

copy number

Store

Responsibilities 

Collaborators 

Maintain inventory 

Members

Respond to query on inventory

Titles, items

Respond to query on members

Active Rentals

Maintain Active Rentals

Lock up returned items

Maintain Policies

Purchase/Invoice

Responsibilities 

Collaborators 

Charged fee (total)

Active Rental

Charged late fee

Policy

Resolves policies

Adjust due dates

Additional Notes from the Reporter

Notes on Overall Design

The core classes in the design are the Rental Copy, Rental Item, Active Rental and Transaction classes. The following descriptions are from notes taken during the discussion:

Rental Item
This class is for capturing identifying information about an item for rent at the store, such as a video or game. The class would provide services such as maintaining the title, indexing words, restrictions, etc. For any one Rental Item, the store may have several Rental Copies. This class is NOT for tracking the location of that Item. However, the store also needs to query the system to see if a particular title is available, where it doesn't matter which particular copy is in (see Rental Copy).
Rental Copy
This class is for tracking the location of a particular copy of a Rental Item. For example, the store may have 5 copies of the movie "Dances with Wolves", and it is important to know that copy #2 is out, and that copy #4 is overdue, and that copy #4 has been rented 103 times while copy #5 has been rented 20 times.
Active Rental
This class essentially is a mapping between a member and a Rental Copy, saying this member is currently renting this particular copy of a title. This class also collaborates with Transaction, where a rental may result in several transactions, such as the basic fee, a late fee, a damage fee, etc.
Transaction
This class simply tracks financial transactions, that is, money coming into the store, and why. A transaction may involve more than one Active Rental, as in the case where there is a 2 for 1 special, or a standard volume discount when renting several titles. The transaction also knows which policy was used to calculate the amount and due date. Transactions may be positive or negative, and need to be tallied to determine the final cost to the customer.

Notes on Purchase Class

The team had lengthy and detailed discussions about how to design the pricing and policy aspect of the system. No one person had a complete solution, but rather the solution was built up with ideas from several people until we had something we all believed was workable. This process showed how a team can be greater than the sum of its parts, and that in a very short time frame the team was working well together. The conclusion was the following algorithm, where the Purchase class is responsible for it:

        For all policies (essentially doing a breadth first search)
                if Policy Applies then
                        If Policy can be combined then
                                Adjust Price and Due Date
                        Else
                                Create a new result for price and due date
        
        Compare result sets using some evaluation or optimization choice, e.g.
        lowest price, longest duration, etc.

Notes on Policy

What are the variables:
  • Rental Item
  • price
  • Member (e.g. number of Active Rentals, gold club)
What are examples of policies:
  • Rental duration/ due date (standard)
  • 2 for 1 (special)
  • pick-up/drop-off location (standard)
  • late (standard)
  • replacement and damage (standard)
  • purchase (standard)

Notes on Issues from Chart #8, Conclusions

The team discussed two alternative class inheritance hierarchies for Rental Item and Rental Copy. In the first case, two parallel hierarchies were created, where Video Rental inherits from Rental Item, and Video Copy inherits from Rental Copy, and similarly for Game Rental and Game Copy. In the second case, only one hierarchy was created for Rental Item and its sub-classes, and Rental Copy never had any sub-classes. The team never discussed a third option of not using a hierarchy, but rather creating a meta system. The team decided not to debate this as a philosophical issue at design lab, and deferred this decision.

The second issue also involved a debate between two philosophical options, to capture status information in a class, or to copy information into a historical class once the instance was no longer active. This applied mostly to the Active Rental class. In the former case, it is necessary to always keep old instances of classes like policy, so as not to create orphan links. The team also decided not to debate this issue, and deferred this decision.

The third issue involved the division of responsibilities between the Financial Category classes, and the Inventory Category classes. This discussion was the main topic of the design lab, and the results are as shown in this report.

The fourth and final issue involved the design for managing store policies for pricing, rental duration, and other issues. This discussion was most interesting, particularly since this area had not been explored by the "user", and was an area that two of the participants had run into previously, without resolution. The results are as shown in this report (see section Notes on Purchase Class).

Final Personal Remarks

Here are a few personal observations:


Report by Gail Harris.