Table of Contents
1. Introduction 3
1.1 Assignment Requirement 3
1.2 Deliverables and Structure (what to submit) 4
1.3 Software Restrictions 4
1.4 How to score high... 4
1.5 Assumptions 5
2. System Requirements 5
2.1 General Requirements 5
2.1.1 User Interface 5
2.1.2 Data Files 5
2.1.2 External Hardware 5
2.2 Data Requirements 6
2.2.1 Categories 6
2.2.2 Products 6
2.2.6 Members 6
2.3 Functional Requirements 7
2.3.1 Payments during checkout 7
2.3.2 Member Registration 8
2.3.3 New Products Entry 8
2.3.4 Category Addition 8
2.3.5 Buying a product 8
2.3.6 Reporting 9
2.4 File Formats and Sample data 9
2.4.1 Categories 9
2.4.2 Members 9
2.4.3 Products 10
2.4.5 Transactions 11
2.4.6 Discounts and offers 11
2.4.7 Vendors 12
2.4.8 Storekeepers 12
2.4.9 Sample file 13
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.
1.2 Deliverables and Structure (what to submit)
You will deliver the following:
1. A ZIP file named MITS_XXX.zip where XXX is student ID. The ZIP file will have the following folders:
• NetBeans project folder (name it as Assignment)
• docs folder which will contain the Project Report (report_ XXX.doc)
a. data folder which will contain the data files (see later sections).
Note: You should use NetBeans IDE for this Assignment.
2. A Project Report named report_XXX.doc, placed in the docs folder of the ZIP file. The report cover must clearly show the name of your team and a list of members. The report must contain:
i. UML class diagrams showing the domain classes (most important classes) of your software. The diagrams may be drawn using tools of your choice (e.g. WhiteStarUML, MS Word diagrams, scanned hand drawings, Rational Rose tool diagrams, etc.). They must show classes, their main attributes and methods (including key parameters), their relationships with roles and multiplicity, uses of inheritance, etc. No text explanation is required for the UML class diagrams.
1.3 Software Restrictions
i. You may use Standared JDK version used in class only
ii. Use JUnit 4.0
iii. Use Swing APIs for building the GUI
iv. Use Java IO APIs for manipulating data from files.
(You may only use text or binary format files. Use of any database or other APIs such as XML etc. is not permitted)
1.4 How to score high...
i. Follow the specification carefully, make the software do what it is supposed to!
ii. Ensure the application works smoothly. Fix the bugs!
iii. Make sure it’s installable: once you’ve built your ZIP file, try unpacking it on a different system, in a folder with a different name, with a JDK at a different location, and verify the batch files work properly.
iv. If you think you know how to make this application more impressive, enhance it as appropriate.
v. Participate in the IVLE forums and help others with their questions.
vi. Do not copy code. You will lose marks for direct use of code from solutions you find elsewhere, and for sharing solutions with other teams.
vii. Write test case classes for as many important classes. Test important classes thoroughly.
viii. Ensure that you create ample data to demonstrate your system
1.5 Assumptions
No system requirements can be specified completely and accurately, using only the English language. Hence please make reasonable assumptions, where requirements are ambiguous. Ensure that you have documented them in your report. Clarify with the instructor on critical doubts.
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.1 User 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.2 Data 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.2 Data 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
2.4 File Formats and Sample data
All data files are currently text-based, so that all values are stored as strings rather than binary data. Each file contains a sequence of records of the same type.
2.4.1 Categories
Categories are stored in the file Category.txt.
Each line comprises comma-separated fields described as follows:
Field 1 – Three letter code of category
Field 2 – Name of category
The following is a sample Category.txt file:
CLO,Clothing
MUG,Mugs
STA,Stationary
DIA,Diary
Your category data file should contain no less than 5 categories in total.
2.4.2 Members
Members are stored in the file Members.txt.
Each line comprises comma-separated fields described as follows:
Field 1 – Name of member
Field 2 – Member id
Field 3 – Loyalty points accumulated so far (-1 indicates a new member)
The following is a sample Members.txt file:
Yan Martel,F42563743156,150
Suraj Sharma,X437F356,250
Ang Lee,R64565FG4,-1
Your member data file should contain no less than 10 members in total.
2.4.3 Products
Each line comprises comma-separated fields described as follows:
The format for each record is:
Field 1 – Product id
Field 2 – Name of product
Field 3 – Brief description
Field 4 – Quantity available
Field 5 – Price
Field 6 – Bar code number
Field 7 – Reorder Quantity (threshold)
Field 8 – Order Quantity (when inventory below reorder level)
The following is a sample Products.txt file:
CLO/1,Centenary Jumper,A really nice momento,315,21.45,1234,10,100
MUG/1,Centenary Mug,A really nice mug this time,525,10.25,9876,25,150
STA/1,VIT Pen,A really cute blue pen,768,5.75,123459876,50,250
STA/2,VIT Notepad,Great notepad for those lectures,1000,3.15,6789,25,75
Your product data file should contain no less than 10 products in total.
2.4.5 Transactions
Each line comprises comma-separated fields described as follows:
The format for each record is:
Field 1 – Transaction id (a monotonically increasing number)
Field 2 – Product id
Field 3 – Member id or “PUBLIC” for non-member
Field 4 – Quantity purchased
Field 5 – Date
The following is a sample Transactions.txt file:
1,CLO/1,F42563743156,2,2013-09-28
1,MUG/1,F42563743156,3,2012-09-28
2,STA/1,PUBLIC,1,2013-09-29
3,STA/2,R64565FG4,2,2013-09-30
2.4.6 Discounts and offers
Each line comprises comma-separated fields described as follows:
The format for each record is:
Field 1 – Discount code
Field 2 – Description
Field 3 – Start date (where applicable or “ALWAYS”)
Field 4 – Period of discount in days (where applicable or “ALWAYS”)
Field 5 – Percentage discount without the percentage symbol e.g. “10” for 10% discount
Field 6 – Applicable to Member (M) or All (A)
The following is a sample Discounts.txt file:
MEMBER_FIRST,First purchase by member,ALWAYS,ALWAYS,20,M
MEMBER_SUBSEQ,Subsequent purchase by member,ALWAYS,ALWAYS,10,M
CENTENARY,Centenary Celebration in 2014,2014-01-01,365,15,A
PRESIDENT_BDAY,University President’s birthday,2014-02-01,7,20,A
ORIENTATION_DAY,Orientation Day,2014-02-02,3,50,A
Your discounts data file should contain no less than 5 discounts in total
2.4.7 Vendors
Vendor list for each category of products will be kept in a separate file. A vendor may supply many categories of products. The entries for each vendor appear in the order of preference in the file. Each line comprises comma-separated fields described as follows:
The format for each record is:
Field 1 – Vendor Name
Field 2 – Description

The following is a sample VendorsMUG.txt file:
Nancy’s Gifts,Best of the best gifts from Nancy’s
Office Sovenirs,One and only Office Sovenirs
Pen’s and Such,Sovenirs and gifts for all occasions
ArtWorks Stationary Store,All kinds of Stationary and Gifts
Each Vendor data file should contain no less than 3 vendors in total.
2.4.8 Storekeepers
For this version, you do not need to store encrypted passwords.
Field 1 – Storekeeper’s Name
Field 2 – Storekeeper’s Password
2.4.9 Sample file
The following is a sample Storekeepers.txt file:
Stacy,Dean56s
Johny,A12ysd45
Your Storekeepers data file should contain no less than 2 Storekeepers in total.
Note, this file can be found on Moodle!