OBJECT-ORIENTED SOFTWARE DEVELOPMENT

1. Introduction
1.1 Assignment Requirement
1.2 Deliverables and Structure (what to submit)
1.3 Software Restrictions
1.4 How to score high...
1.5 Assumptions
2. System Requirements
2.1 General Requirements
2.1.1 User Interface
2.1.2 Data Files
2.1.2 External Hardware
2.2 Data Requirements
2.2.1 Categories
2.2.2 Products
2.2.6 Members
2.3 Functional Requirements
2.3.1 Payments during checkout
2.3.2 Member Registration
2.3.3 New Products Entry
2.3.4 Category Addition
2.3.5 Buying a product
2.3.6 Reporting
2.4 File Formats and Sample data
2.4.1 Categories
2.4.2 Members
2.4.3 Products
2.4.5 Transactions
2.4.6 Discounts and offers
2.4.7 Vendors
2.4.8 Storekeepers
2.4.9 Sample file

1. Introduction
To show your ability to create an object-oriented program, you will construct the Java application as detailed in this document.
Your work will be assessed not only on the basis of how well the program works, but also on how closely you have fulfilled the specification, how well you have structured your code. You are advised to spend some quality time in team discussions to determine a suitable design.

1.1 Assignment Requirement
Your solution should demonstrate the following. You would each be individually assessed on your solution and would be required to establish your learning and understanding of the items stated in this section with adequate theoretical/technical explanations and demonstration of codes and other artefacts during your presentation;

Req-1: Strong understanding of Programming concepts
a. Appropriate and correct use of language (java) constructs
b. Efficient development of algorithms and optimal use of looping constructs
c. Proper structured code using static methods, constants and libraries
d. Creation of appropriate classes based on case study description

Req-2: Create solution design based on case study specifications described here
a. Evidence of your analysis of the case description to derive appropriate design specifications using class diagrams and other UML notations.
b. Define classes in java that would demonstrate accessors, modifiers, instance methods, constructors

Req-3: Comprehensive Solution Development
a. System building using concepts of aggregation of classes.
b. Based needs demonstrate the use of appropriate collections (eg: arraylist, hashmap, iterators etc.)
c. Craft reusable method signatures with appropriate arguments and return values using wrapper classes.
d. Demonstrate aggregative operations on collection using build in libraries

Req-4: Advanced OOP concepts
a. Build class hierarchies with OO inheritance and interfaces
b. Use of appropriate over-riding and over-loading of methods
c. Demonstrate polymorphic class behaviour and late binding

Req-5: UI principles
a. Use of appropriate visual components
b. Event driven programming with exception handling.

Req-6: Competence in Advanced concepts
a. Use of generics
b. Identification and use of design patterns
c. Practices for error free coding including exception handling, error messaging through unit and system level testing.

2. System Requirements

You are assigned to implement a simple point-of-sale system for automating the University Souvenir Store.
The system, operated by the store keeper, will provide facilities to make payment, replenish stock, check inventory, member registration. The present system is GUI-based, with flat files to store data.
The design of your system should be flexible enough to cater to new requirements and/or changes in the requirements.
Currently there is only one user of the system - the store keeper.

2.1 General Requirements
2.1.1User Interface
The application will be GUI-based using Java Swing APIs.
When the user starts the system, he/she is shown a login screen. Upon successful login, he/she is taken to a main menu screen in which various options are shown. This may take the user to other screens based on the option chosen. Each of the functions described below should end by returning the user to the main menu screen.
2.1.2Data Files
The data for the inventory and users, as well as transaction records, are currently stored in text-based files. The exact formats of these files is detailed in a later section. It is mandatory that you use those formats.
The data files must be read when the application starts up, and updated whenever needed (e.g. when a new member is added, etc). The system should have the current state persisted at all times, so that even anomalous termination of the application does not result in loss of data.
2.1.2 External Hardware
The system will normally use bar-code readers to obtain the product code (from the product label) and the member id (from the membership card). However, for the time being, these bar-code readers are unavailable. Operators will therefore be prompted for the codes at the console.
Similarly, there will be a receipt printer and an adhesive label printer (for printing barcode labels). For this version of the software, you should build placeholder classes for these devices, that output text to the console.
2.2Data Requirements
2.2.1 Categories
The products are classified into categories ("clothing","mugs", "stationary", "diaries", etc.). Each category is identified by a "category id", which is a three-letter code (e.g. "CLO" for "clothing"). The list of categories is not hardcoded, but rather stored in a data file named Category.txt as specified in a later section; categories can therefore be added by the store keeper.
2.2.2 Products
Each physical product in the store has a "product id" that identifies it uniquely. The product id is assigned automatically by the system, and consists of the category code, followed by a slash character, and a number which is assigned sequentially to products in the same category, starting from 1. For example, the twelfth product to be registered in the "clothing" category would be assigned a product id "CLO/12". The list of products is stored in a data file named Products.txt as specified in a later section.
2.2.3 Vendors
The University keeps a list of vendors who supply the product. Vendors related information are stored in a data file named Vendors.txt as specified in a later section.
2.2.4 Transactions
Every billing transaction should be logged in a data file named Transactions.txt as specified in a later section.
2.2.5 Discounts
Discounts and other promotional offers are stored in a data file named Discounts.txt as specified in a later section.
2.2.6 Members
Staff and students can become members of the store and avail discounts. This requires submission of an application form accompanied by a document of identity (student or staff card).
Members are identified by their "member id", which is identical to their student/staff card number. The list of members is stored in a data file named Members.txt as specified in a later section.
Note: The general public are not eligible for members-only discounts. However, there may be other discounts for which they may qualify e.g. on special occasions. Furthermore, they are also not eligible to become members.
Store Keepers
User names and passwords of all store keepers are stored in a file called StoreKeepers.txt

2.3 Functional Requirements
2.3.1 Payments during checkout
During checkout, the system will request for payment to be affected. The system will display an itemised list of charges, with a total, and will prompt the store keeper to enter the amount tendered and/or points to be redeemed (see the section on "Discounts, offers and loyalty points" below). If points are redeemed during checkout, the Members data file will be updated to reflect the latest points remaining. Customers can pay using their loyalty points as well as cash or a combination of these for a single transaction.
The store keeper receives the payment and enters the payment amount and/or the number of points to redeem. The total tendered, cash as well as dollar-equivalent of the loyalty points, cannot be less than the total amount. At this point, the store keeper may decide to cancel the payment by selecting the "Cancel" option.
If a valid amount is tendered, using a combination of cash and/or loyalty points, the system will compute the change to be returned and print a receipt using the receipt printer.
Should the quantities of any product purchased by the customer result in the inventory levels falling below a specified threshold (reorder level), an alert message is automatically printed for the store keeper indicating which products are affected and the present quantities in the inventory. Note that this message is not printed on the customer's receipt and is strictly for the store keeper only.The reorder levels are specified in the Products data file.
Discounts, offers and loyalty points
Discounts may be offered to new members when they make their first purchase, say, 20%. The discount amount should be configurable. For subsequent purchases, members are entitled to a members-only discount of, say, 10% (also configurable).
The store will also offer discounts on special occasions such as Centenary Celebration, University President's birthday, National Day and Orientation Day, which all customers are eligible to enjoy, not just members. The store may offer different discounts for different occasions. Note that discounts are not cumulative (e.g. 10% + 5% = 15%) - only one discount can be offered at any given time; the highest of the offered discounts will apply.
Furthermore, members may accumulate loyalty points (stored in the Members data file) and redeem the points after accumulating sufficient points. The dollar-to-point value (e.g. $10 spent = 1 additional point) and the points-to-dollar redemption value (e.g. 100 redeemed points = $5 worth) can be hard-coded if you so wish.
Check and replenish inventory
The store keeper should be able to generate a list of products with inventory quantities below a specific threshold. The threshold for each product is configured in the Products data file. The store keeper should be given an option to generate a purchase order for all items below their thresholds.

2.3.2 Member Registration
The new member fills out a (paper) membership application including their name and student/staff card number. The clerk requests the computer system to display the "New member" screen and enters the form information.
The system then
- uses the student/staff card number as the membership number
- stores the member in the members database.
2.3.3 New Products Entry
1) When new products arrive, the store keeper requests the system to display the "New Product" screen
2) For each Product, the store keeper enters
- the Product's category
- the Product's title, in addition to other information
3) The system then
- automatically assigns a "product id" to this product, according to the rules above
- enters the product in the product data base
- displays an option for continuing to enter information about another product

2.3.4 Category Addition
1) The store keeper can add a new category requesting the system to display the "New Category" screen.
2) The system displays a list of all categories currently available in the system.
3) The store keeper is then prompted to enter
- A three-letter code for the new category
- A name for the category
4) The system then checks if the category code already exists, in which case it will print out an error message and terminate the function, returning to the main menu. If the category code does not already exist, the new category is added to the data file, and the user is returned to the main menu.
2.3.5 Buying a product
1) The store keeper requests the system to display the "Check Out" screen, and reads the bar-code on the student/staff card to determine the identity of the member.
2) The store keeper reads the product id from the bar-code sticker on each Product being purchased.
3) The member is required to make immediate payment. If payment is not received, the check-out operation is cancelled, and the user is returned to the main menu.

4) On receiving the payment, the system registers the purchase for each Product, in the Transactions data file, as specified in a later section. The user is returned to the main menu.
2.3.6 Reporting
The system must be able to print out to the screen some simple reports; in these reports, each record should be displayed as a brief one-liner. The following reports must be provided:
- A list of all categories, and their category id
- A list of all Products available, and their description (id, quantity, price, etc)
- A list of all transactions for a given date range sorted by product id. You should also include the product name and description in this report.
- A list of all members in the system and their details

Attachment:- Assignment.rar