The hardware store has decided to expand its business and sell appliances in addition to regular hardware products.
Furthermore, the store wants to keep information about the employees working in the store as well as sale transactions.
For every item, the software will store the same basic information as in assignment 1, plus some additional information. General information about all items:
ID number: string of length 5
Name: string
Quantity: int
Price: float
The hardware store has decided to expand its business and sell appliances in addition to regular hardware products.
Furthermore, the store wants to keep information about the employees working in the store as well as sale transactions.
For every item, the software will store the same basic information as in assignment 1, plus some additional information. General information about all items:
ID number: string of length 5
Name: string
Quantity: int
Price: float
For small hardware items, the software will also keep information about the
Category: string (same as in the previous assignment).
For appliances, the store will keep information about the
Brand: string
Type: string – [Refrigerators, Washers&Dryers, Ranges&Ovens, Small Appliences]
The users are of two types, employees and customers. For all users, the following information is kept in the system:
ID (unique number generated for each user): int
First Name: String
Last Name: String
Type of user | Additional Information needed |
Employee | Social Security Number: int Monthly salary: float |
Customer | Phone number: String Address: String |
In addition, the following information is kept for each user type:
Finally, the hardware store records information about completed sale transactions. Each completed transaction includes the following information:
Item ID: String
Sale date: Date
Sale quantity: int
Customer id: int
Employee id (who completed the sale): int
Note that the customer id, the employee id and the item included in a sale transaction, should match existing entries of customers, employees and packages already existing in the database. The new functionality of the shipping store system looks like this:
1. Show all existing items records in the database (sorted by ID number).
2. Add new item (or quantity) to the database.
3. Delete an item from a database.
4. Search for an item given its name.
5. Show a list of users in the database.
6. Add new user to the database.
7. Update user info (given their id).
8. Complete a sale transaction.
9. Show completed sale transactions.
10. Exit program.
For #2, when the user selects to add a new item to the database, they should be asked to specify what kind of item before they enter item information.
The same applies for #6 regarding the user types.
For #8, when an item is sold, a new completed transaction record is created, and the corresponding quantity is automatically removed from the inventory.
The program should not allow a transaction to be completed if any of the items or user does not exist in the database.
A user has to be added to the database before a transaction can be completed.
Create and object-oriented Java program that implements the hardware store management software described above.
Make use of the inheritance and polymorphism concepts that we saw in class. E.g. toString() method used to format information about an item or a user, may be defined multiple times in the different classes and subclasses used in the program.
Try to make your program as robust as possible, by using Exception handling to deal with possible problems that may occur during the program execution. You may also create your own custom exception classes to handle bad input from the user, etc.
This time do not save your data as text files, but as serializable objects.
You may use more than one file to store your data, if it is more convenient to you.
Print out the item and user information in a formatted manner.
Output headers and make the data line up in columns under the headers.
Use a standard Java coding style to improve your program's visual appearance and make it more readable.
Use Javadoc for every public class, and every public or protected member of such a class.
Other classes and members still have Javadoc as needed.
Whenever an implementation comment would be used to define the overall purpose or behavior of a class, method or field, that comment is written as Javadoc instead. (It's more uniform, and more tool-friendly.)