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

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:

·
\src
folder which will contain the full set of working source files for this application, i.e. the
*.java
files, arranged hierarchically into folders according to their path. The system must compile and run without errors.

·
\classes
folder for the compiled classes. This will be empty (i.e. class files must not be provided in the ZIP file).

·
\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. But make sure that the batch files work.

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.dat
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.dat
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.dat
as specified in a later section.

2.2.4 Transactions

Every billing transaction should be logged in a data file named
Transactions.dat
as specified in a later section.

2.2.5 Discounts

Discounts and other promotional offers are stored in a data file named
Discounts.dat
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.dat
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.dat

2.3 Functional Requirements

2.3.1 Payments during checkout

During checkout, the system will request for payment to be effected. 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.dat.

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.dat
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.dat.

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.dat
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.dat
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.dat
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.dat
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.dat
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.dat file:

Stacy,Dean56s

Johny,A12ysd45

Your Storekeepers data file should contain no less than 2 Storekeepers in total.