inventorym/Project_DescriptionArtManagement.md

OOP Project Description

Requirements:
You are to design prototype software (stand-alone application loaded on business’s local computer) to manage art inventory and transactions. Your software will be used and called by User Interface (UI) that someone else will be designing.

Your software will allow loading and managing art inventory and current transactions for the business. When the system starts up, UI may request to load the list of available art and/or current list of transactions by proving where to load from each or it may request the load to happen after the system is already up and running. 

For the prototype the data will be loaded and saved in text files on the local system (for the final product outside the scope of this project, server with database will be used). 

Note that UI will handle the login and authorization of who can change the inventory and access control is outside of the scope of the system you are designing.  

There are four different types of art in the inventory allowed:  paintings, drawings, prints, and sculptures.  Each art piece includes 10 digit id, price, date when created (year only), title of the art (e.g. “family on the beach”), description (max 500 characters), and author’s name. Paintings also include height in inches, width in inches, style (e.g. abstract, surrealism, impressionism, etc.), technique (e.g. oil, acrylic, watercolor, etc.), and category (history, portrait, genre, landscape, or still life).  Drawings also include style ((e.g. abstract, surrealism, impressionism, etc.), technique (e.g. pastel, colored pencil, charcoal, etc.), and category (history, portrait, genre, landscape, or still life).  Prints also include open edition type (canvas, paper, or photo) and category (history, portrait, genre, landscape, or still life).  Sculpture also include material (e.g. stone, metal, ceramic, wood, glass, etc.) and weight in ounces. 

Art cannot exist without these values and they cannot be changed through this system.

A customer of the business can buy one or more of the art pieces in a single transaction.  Customer data will include first name, last name, mailing address, phone number, and email. All the data must have values at creation but it can be changed. 



Each transaction will include a unique transaction id generated by UI, customer data, art pieces to be bought, date of transaction, and transaction price. Transaction must have id, customer data, and at minimum one art piece at creation.  All transaction data can be changed except id and can only be changed until the transaction is completed.

The transaction price will include art price plus shipping costs. Transaction price and date will be set when the transaction is completed as requested by the customer. That is when the customer would pay but that is outside of the scope of the system.

Transaction shipping cost will be calculated as follow:
(1) Basic shipping cost per art piece is $10.99
(2) Sculpture will have additional cost based on weight:  $0.20 per ounce
(3) Painting will have additional cost per height*width: 
	(a) less than 100 square inches add $5.99
	(b) between 100 and 300 square inches add $10.99
	(c) above 300 square inches add $15.99
	
Note that null transaction date means the transaction has not been completed yet. Art work is not removed from the inventory until the transaction is completed. If customer requests to complete the transaction but art work is not in available list, the transaction will fail to complete. Transaction can be removed if it is not completed. Once transaction is completed it cannot be changed nor removed. The transaction file will store both completed and not completed transactions.

Your system must support the following functionality:
1. Add new art object to the inventory. Your manager must check that the art is not already in the inventory before adding
2. Remove art object from the inventory
3. Return a list of all art objects from inventory 
3. Add a new transaction object to the list manager is handling
4. Calculate and return transaction price 
5. Complete transaction 
6. Remove transaction object
7. Format and return transaction data in print format
8. Retrieve and return transactions based on:
    • customer email
    • transaction date
    • transaction id 
    • art id
9. Update inventory file(s) on local system
10. Update transaction file(s) on local system
11. Any other functionality needed to support the above requirements
 

Note: You can assume the number of current transactions and available art is small enough to load all into memory as needed.

Your system will need the following user defined exceptions: 
1. On adding or removing art if duplicate art exists on add or art not in inventory on remove throw unchecked user defined exception called InvalidArtOperationException when violation detected. The exception will extend RuntimeException. The exception message should indicate which operation was attempted and why failed.
2. On adding or removing transaction if duplicate transaction exists on add or transaction cannot be removed throw unchecked user defined exception called InvalidTransOperationException when violation detected. The exception will extend RuntimeException. The exception message should indicate which operation was attempted and why failed.
3. On complete transaction request if it cannot be completed, throw unchecked user defined exception called InvalidTransactionException when violation detected. The exception will extend RuntimeException. The exception message should indicate what operation was attempted and why exactly it failed.

UI is outside the scope of your design but your system needs to have all the functionality it would need to satisfy the requirements.

As you design the system, you need to make sure it is consistent and it only has the interfaces (constructors, attributes and methods) that are needed by the required functionality. You cannot arbitrarily add new functionality to the system.
* ****