Project Description
In this fourth phase of the project you will be experimenting with inheritance
and polymorphism within your application.
The DVD rental system
The DVD Rental System manages a list of customers who want to rent DVDs,
a list of available DVDs, and a list of desired DVDs for each customer (the
customer's "queue"). The system also reacts to the following commands:
OPEN
- Open and read a DVD stock file that represents the DVDs that are currently
in-stock.
- If the file does not exist - display an error
- If the file is empty - display an error
- You may assume all data is correct in stockfile.
CUSTOMER
- Add a customer to the system
- If customer already exists, display an error.
RENT
- Rents DVDs to a customer.
- Until the customer's quota is full, finds the first DVD on the customer's
queue that is also in-stock, removes it from the stock, and adds it to the
customer's rented list.
- Once the quota is full, a receipt is printed.
- If the quota cannot be filled and a DVD was rented, a receipt is printed.
- If no DVD was rented, then no receipt is printed.
RETURN
- Return the DVD for the customer.
- Removing it from the customer's rented
list and returning it to the stock.
- If the DVD was not rented by the customer, display an error.
QUEUE
- Add a DVD to a customer's queue (list of DVDs they want to rent).
- If customer does not exist, display an error.
- If DVD is in the system (it is either in-stock or rented by another
customer) - allow it to be queued.
- If DVD does not exist in the system, display an error
- The same DVD can be queued multiple times.
PRINT_DVDS
- Prints a list of in-stock DVDs (DVDNumber, NbrOfDiscs, Title)
PRINT_CUSTOMERS
- Prints all customers and their current rentals -
all personal information (name, username, CC#, address, city, state, zip)
followed by all currently rented DVDs (DVDNumber, NbrOfDiscs, Title)
PRINT_USER
- Prints the queue for a particular user
- If username does not exist, display an error.
- If the user has no DVDs in their queue, then leave the queue area blank.
PRINT_SORTED_CUSTOMERS
- Optional
- Prints a sorted list of customers and their current rentals -
all personal information (name, username, CC#, address, city, state, zip)
followed by all currently rented DVDs (DVDNumber, NbrOfDiscs, Title)
- Sorting is done based on username (ASCII sorting)
PRINT_LOG
- Optional
- Prints the transaction log for each user
- Prints the logs in same order as PRINT_CUSTOMERS
- If a user has no transactions, then leave the area blank or print an
appropriate message.
Data
Rental System
The Rental System manages the collection of Customers and in-stock DVDs. You
may also have the Rental System manage other components according to your
design. However, for this project, your Rental System class MUST have at the
minimum:
- a collection of Customers
- a collection of DVDs
Customers
Basic Functionality
Customers who rent DVDs are essentially the same as in previous projects.
There are multiple customers allowed in the system. Extensions to the
representation of a Customer are described in the next section.
Customers each have the following information, you may represent these in
a variety of ways and are not limited to this exact representation:
- First name - sequence of any characters without spaces
- Last name - sequence of any characters without spaces
- Username - sequence of alphabetic, numerical, or the underscore ('_')
characters - each username is unique
- Credit Card number - sequence of digits
[0 - 9999999999999999], displayed as 16 digits
- Street Address - sequence of any characters with spaces
- City - sequence of any characters with spaces
- State - sequence of 2 characters (upper or lower) that match the 50 US
states
- Zip - sequence of digits [1000 - 99999], displayed as 5 digits
- Queue - a list of DVDs the user would like to rent
- Rented List - a list of DVDs the user is currently renting
Polymorphic Functionality
There are now three different kinds of customers in the Rental System. Your
project must use Inheritance and Polymorphism to implement a Customer class
Hierarchy. Each kind of Customer has a unique cost associated with renting
their DVDs as well as a unique limit to the number of DVDs that they can rent.
Customers may not change types - once added to the system, they will remain
the same type of Customer. Your Customer class hierarchy should look
essentially like this:
- Basic Customer - most basic deal
- Pays $.99 per disc
- Limited to 3 DVDs at a time
- Extended Customer - better deal
- Pays a flat fee of $1.99 each time they rent 1 or more DVDs
- In addition, pays $.25 per disc
- Limited to 5 DVDs at a time
- Premium Customer - best deal
- Pays a flat fee of $3.99 each time they rent 1 or more DVDs
- Limited to 10 DVDs at a time
DVDs
DVDs are essentially the same as described in Project 1. Multiple copies of
the same DVD are allowed. It can be assumed that the first DVD added to
the system has the correct Number of Discs and Title information.
DVDs each have the following information:
- DVD Number - unique identifier, sequence of digits [1 - 999999]
- Number of Discs - sequence of digits that represents the number of
disc [1 - 100]
- Title - sequence of any characters with white space
Program Requirements
Polymorphism
In order to make polymorphism work for this project you will have to implement
all instances of Customer objects as dynamic memory. While you need not
implement RentalSystems and DVDs as dynamic - if you got it working in Project
3, then you should leave it.
You are required to create at least one virtual or pure virtual method
for use in your Customer classes. You may choose whether the method is pure
or not, but your selection should be reasonable and should represent good
OO design principles. You should place all other methods or data members
required for use by the different Customer classes at appropriate levels of
the hierarchy.
Utility Class
You have been provided with a "Utility" class that has one static method that
you may use to correctly parse the command file. If you choose not
to use the Utility class, then you will have to rely upon the correctness of
your own implementation. You have been provided with the .h and .o files.
You will not be supplied with the Utility class code, you do not need it.
You can find Utility.o, Utility.cpp and Utility.h in the following location:
/afs/umbc.edu/users/d/a/dana3/pub/CMSC202/p4/
The one public method of the Utility class is:
static bool GetCommand(istream& sin, vector& command);
The GetCommand method makes the following guarantees:
- Returns true if the command was correctly formatted and the data was of
the correct type (digits versus strings)
- Returns false otherwise
- Parses the data, pushing each individual item onto a vector
- First item in the vector is the command name
- Each parameter to a command is a single entry in the vector
- Validates that all numbers are composed of digits
- Validates that the state in the address is one of the 50 states
- Validates the username by verifying that all characters are alphabetical,
numerical or the underscore ('_')
- Stock file is not read, nor tested for existence
- The state of the vector is undefined if GetCommand fails
- The command as read from the file will be printed to the standard output
stream
- Validates the Customer Type is one of the three acceptable
types.
There are constants for each command included in the Utility.h so you do not
have to declare those in your own code.
Extra Credit
In order to be considered for the extra credit, you must submit a README file
to the graders describing what you did.
Log File - 10 pts
In many systems, we want to be able to track what events occured on a
per-customer basis. In order to support this functionality, you must
implement a class to support a log for each customer. Each log is simply a
record of transactions for that particular customer. You may print these to
the screen in any logical method; however, it should be tabularly structured.
All commands that have been processed during this SINGLE run of your program
should be recorded in a log. Obviously PRINT commands and OPEN commands will
not be logged. However, QUEUE, RENT, and RETURN commands should be logged.
The new PRINT_LOG command supports this functionality.
Customer Search - 10 pts
As our system gets larger, searching for Customers will become time intensive.
Since this is one of the most common actions in our system (i.e. the Customer
must be found for most commands in the system), we want to optimize the
search for a Customer.
For this 10 pts of extra credit, you must implement a more optimal search
technique through your Customer collection. You can implement any search
technique that works in O(log(N)) time or better. This means that on average,
there are less than or equal to log(N) comparisons needed to find a Customer.
There are many acceptable stategies, some of the easiest would be to store a
sorted version of the Customer collection and then perform a Binary search on
the collection. However, not all strategies require a sorted collection. For
example, storing all of your Customers in a programmer-defined Hash Table
would be another alternative (although more complicated). You are encouraged
to scour the text and internet for alternatives to these strategies if you
are looking for something in-between. However, you MUST implement the strategy
that you choose from scratch, you may not use STL classes or other built-in
functions to perform the search for you (i.e. you can't use the STL
hash-table or map to search for your customers).
The PRINT_CUSTOMERS command must continue to print the Customers in the
order they were originally inserted into the system.
Command File Requirements
The name of the command file will be read from the command line. You should
thoroughly test your program by developing your own command file. You do not
need to submit your command file. We will test your program using our own
command file(s).
Your program is required to repeat the command as read from the file. The
Utility class will take care of this for you, if you use it.
Commands
Please note that there have been minor changes to the command parameters.
Valid command keywords are all uppercase.
Valid commands for the system are as follows:
- OPEN <stock filename>
- CUSTOMER <first name> <last name> <username>
<card number>
<customer type>
<address>
<city> <state> <zip code>
- RENT <username>
- RETURN <dvd number> <username>
- QUEUE <dvd number> <username>
- PRINT_DVDS
- PRINT_CUSTOMERS
- PRINT_USER <username>
- PRINT_SORTED_CUSTOMERS [optional - old extra credit, will not be used]
- PRINT_LOG [optional - extra credit]
Command File Error Checking
- <customer type> must be one of the following strings:
"BASIC", "EXTENDED", or "PREMIUM". Each must be capitalized. The Utility
class will validate this for you.
- If a command is incorrect in any way (format or content), it shall be
discarded and processing of the command file shall continue. Must include
an error message.
- If a command cannot be executed (like queueing a DVD for a non-existant
customer), a message shall be printed and processing of the command file
shall continue.
- Data must be validated. Utility takes care of this, mostly. Integer
ranges are not validated by Utility.
- Names, addresses, and other "word" based items, unless
specifically limited - they may contain any printable character.
- Printable characters are defined as any character that can be typed on the
keyboard. You need not validate these characters at all.
Sample Command File
Commands that have been tested and described in previous projects have been
left off of this example to eliminate clutter. However, your program must
still support the complete functionality of the system as described above.
<![CDATA[
OPEN stock.txt
CUSTOMER Fred Flintstone fflint0 1234123456785678 BASIC
123 Bedrock LN Apt. 7
Rock Vegas NV 12345
CUSTOMER Barney Rubble brubblerubble 1234567812345678 EXTENDED
123 Bedrock LN Apt. 8
Rock Vegas NV 12345
CUSTOMER Betty Rubble blueBetty 1234567812345678 PREMIUM
123 Bedrock LN Apt. 8
Rock Vegas NV 12345
QUEUE 12345 fflint0
QUEUE 423644 fflint0
QUEUE 826918 fflint0
RENT fflint0
RETURN 12345 fflint0
RETURN 423644 fflint0
RETURN 826918 fflint0
QUEUE 12345 brubblerubble
QUEUE 423644 brubblerubble
RENT brubblerubble
RETURN 12345 brubblerubble
RETURN 423644 brubblerubble
QUEUE 12345 blueBetty
QUEUE 423644 blueBetty
RENT blueBetty
RETURN 12345 blueBetty
RETURN 423644 blueBetty
]]>
Stock File
You can assume that any stock file that we test with your program is
properly formatted and that all DVD data is valid. You need not perform ANY
error checking on the DVD file. The stock file represents all the DVDs that
are currently "in-stock" (since the inventory is taken every evening).
For now, you will assume that another file processes the inventory every
evening and provides your system with an up-to-date copy of the stock every
morning.
Sample Stock File
<![CDATA[
12345 2 Harry Potter and the Chamber of Secrets
423644 1 Matrix: Reloaded
826918 4 Lord of the Rings: The Fellowship of the Ring
759203 1 Dumbo
927833 3 Hunt for Red October
32145 1 Pi
928173 1 Hitchhiker's Guide to the Galaxy
]]>
General Requirements
- In keeping with course standards, main( ) will be implemented in a file
named Proj4.cpp.
- Prototypes for any helper functions called from main will be located in
Proj4Aux.h and the functions themselves implemented in Proj4Aux.cpp.
- Each class will be defined in a separate header (e.g. Customer.h) file
and implemented in a similarly named .cpp file (e.g. Customer.cpp).
- You must provide a makefile for this project which compiles and
links all files when the grader types
make Proj4.
- Your executable must be named Proj4.
Note that not all of the programming details have been spelled out for you.
For example, the rental system must keep track of which DVD is rented by whom,
but there's no indication about how that should be done.
This is intentional....you are required to give the project design
serious thought before writing code. Remember to think ahead to what might
be assigned in future projects and design your classes so that they are
easily modifiable.
Program Output
Your program's output must adhere to the following requirements:
- Customer credit card numbers must be displayed in the form
1234-5678-9012-3456.
- All monetary values must be displayed with 2 decimal places.
- When displaying a list of DVDs or customers, data must be aligned in
columns.
- Lists of DVDs/customers shall be displayed in the order DVDs/customers
are added to the rental system.
- As the stock file is processed, messages informing the user of each DVD
that is being added shall be displayed
For purposes of formatting output only, you make the following
assumption:
- The renter's first and last name total no more than 20 characters.
- The renter's username totals no more than 20 characters.
You must provide the makefile for this project. Use the makefile provided to
you for project 1 and modify it appropriately. If you don't change the
names of the files (much) from project 1, the changes will be minimal.
The make utility can also be used for compiling a single program without
linking.
For example, to compile Box.cpp, type make Box.o.
In addition to compiling and linking your files, make can be used
for maintaining your directory. Typing make clean will remove any
extraneous files in your directory, such as .o files and core files.
Typing make cleanest will remove all .o files, core, Proj4,
and backup files created by the editor. More information about these
commands can be found at the bottom of the makefile.
The grade for this project will be broken down as follows. A more detailed
breakdown will be provided in the grade form you receive
with your project grade.
