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

• automate check-in and check-out
• flexible pricing, e.g. 2 for 1, new release rate, Tuesday special, ...
• who has what
• who owes what (and why)

Produce

• list of objects
• relationships (see CRC cards)
• responsibilities (see CRC cards)
• deferred decisions
• walk through a scenario
• change case impact analysis

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

• Store
• Employee (?)

Category Membership

• Member
• Contact Track

Category Inventory

• Rental Item
• Rental Copy
• Shelf Product
• Active Rental
• Historical Rental

Category Accounting

• Policy
• Transaction
• Purchase

Chart #4 Assumptions

• there exists a database
• using third party GUI product
• using third party name and address matching
• scope out cash drawer
• date means date and time
• there exists access/security/login

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

• Look at Run Time Requirements for responsibilities/attributes (Done)
• Ask Doug (user) what we did that was NEW (Not Done)
• Decide on alternative sheet 7 vs. sheet 8 (Not Done)
• Handle special cases (e.g. household/member relationship with address) (Not Done)
• Check if design handles "opened vs. closed" styles (Not Done)
• Reserve functionality (Not Done)

Chart #8 Conclusions

• flexible policies are neat, and hard to design; they isolate change impacts
• Four interesting issues:
  1. two alternative inventory models
  2. object has state vs. historical and current
  3. responsiblity sharing re. Inventory Category and Financial Category
  4. Policy resolution
• Change Case impact analysis suggested most changes were additions (we had GOOD design team); and we came up with more general design choices
• Had to defer many decisions because of time limits

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:

• use cases work effectively, the Video store problem definition was very well written using this technique
• the Design Lab is a "toy" environment, at least two participants had attended previous design lab, therefore they had optimized for the environment
• common language and notation for object technology has evolved and is maturing, this makes things easier to discuss, but also introduces different baggage where each person has a slightly different understanding of a concept but all using same word; the common language is a double edged sword
• assumptions about third party tools are not insignificant, because these can interact with each other and cause problems
• behaviour driven versus data driven analysis and design is still fuzzy, many claim to be doing behaviour driven because they are using CRC cards, but looking at the cards you see data; this could mean that its in fact better to understand the data relationships first, and then re-factor as behaviour is added; is this so bad considering that most behaviour requires data?
• the change case impact analysis mostly resulted in additions or changes to an isolated group of classes, but not one was restricted to run time impact; why?