Background
You are asked to develop a GUI program to be installed in a stamp-selling machine in Post Office. This machine sells postage stamps for various types of items (such as parcels and letters). At the end of shopping, the program will output an invoice and a list of purchased stamps to a text file with extension (see an example of output file in Figure 1). It is assume that the list of stamps can be divided and used by the users in their post items. Staff in the Post Office only needs to check the stamp on each item and arrange the delivery.
Your software should sell stamps for 4 types of international post (below) based on the price guide given in this assignment.
- Parcel delivered by air
- Parcel delivered by sea
- Letter delivered by air
- Greeting card delivered by air
Software inputs
Inputs to your system consist of user inputs and file inputs. For example, to buy stamps for 2 letters, users should enter the weight, destination and quantity into the system. The system should calculate the cost based on the price guide.
Since your system only handles 4 types of post items listed in Section 1, we highlight the relevant data (such as country, zone, maximum item weight, and unit price) in the price guide, and summarize the data in a list of input files. These input files are included in this assignment. Data in these files should be loaded into ArrayList when your software starts the execution. After that, your program should get inputs from the users and sell stamps.
You are free to modify the format of input files when developing software; however, you should submit the revised files together with the source code for tutors to run your program. If you did not submit your own data files, we will use our files to test your program.
Software requirements
Functionality requirements
- Your software should support continuous shopping activities in Post Office. If you demand the next users to restart the software each time they do shopping, your software does not fulfill this requirement.
- Once the users submit the detail of an item (such as weight, destination and quantity for “letter delivery”), the item cost should be calculated. Detail and cost of each item should be shown in the shopping cart. The shopping cart should display the total cost of the items within it. Users are allowed to delete an item in the shopping cart. The software should ask the users to confirm the deletion before removing an item from the cart.
- Once the users complete shopping, the software should ask the users to provide credit card information (credit card number, expiration date, billing address, and name of the card holder). Your software can skip online validation of cards, but must ensure that 2 positive numbers (> 0) are entered as card number and expiration date, and 2 non-empty strings (containing more than just white spaces) are entered as billing address and holder’s name.
- After completing the payment, the content of the shopping cart will form the content of the invoice. Your software should output the invoice & a list of purchased stamps to a text file with extension (see an example in Figure 1). This file should be given a unique name, indicating the shopping date and time.
- Your software should handle special cases, such as the following:
- if the item to be added to the shopping cart has zero cost
- if the shopping cart to be paid has zero cost
- if users want to quit the shopping
- if the weight of an item to be delivered exceeds the weight limit stated in the price guide
- if there are more than one entries for the same item delivery. For example, during the shopping, users may enter 1*seasonal greeting card (sent in Nov/Dec) twice.
One way to handle (e) is to increment the quantity of this item in the shopping cart, and print [2* seasonal greeting card] instead of [1*seasonal greeting card twice]. However, you are free to decide a better handling strategy yourself.
Graphic User Interface
You need to create a Graphic User Interface (GUI) for the functions in Section 3.1. The requirements of your GUI are as follows:
- Your GUI should consist of JFrame, JDialog, JTextfield, JTextArea and JButton. Events related to these components should be handled. You are free to use more GUI components other than the ones listed here.
- These components should be displayed using Layout Managers.
- Use setTitle() method of JFrame to add your team number and IDs of group members in the main window.
- Your software should have good GUI and event handling design, so the users find the software user-friendly (easy to learn/navigate the system). Your GUI must be responsive. For example, after clicking a “Submit” button, the software should immediately return a message, such as “File created” instead of letting the users guess the progress.
Despite that some IDEs can create code for GUI, you are discouraged to use it in this assignment. If you do it, you give up the opportunity to exercise GUI programming.
Code created by IDE is very different from that manually coded. Tutors can distinguish them very easily. If your tutor had any doubt of your GUI code, they will not mark your GUI work, as reflected in the Marking Scheme for Stage 2.
Exception handling
Your program must avoid or catch all kinds of exceptions, so software execution won’t be interrupted and it won’t enter any abnormal state. When handling exceptions related to user inputs, your system should return meaningful error messages so the users can correct their inputs.
Tutors will assess how your software handles exceptions related to the followings:
- Input file stream
- Output file stream
- User inputs
- GUI related (other than user inputs)
- Other exceptions (not listed above)
Developing environment and settings
This subject has a significantly large number of students. To allow the tutors to complete marking of this assignment in a timely manner, you must strictly follow the following 3 requirements when developing software.
- You must store ALL your source code in the SAME working directory; in other words, you cannot group classes using packages.
- You must ensure that the input files are read from the same directory as the source code, and output files are also written to the same directory.
- The java file with the method must be named “Assign.java”. We will use the command “java Assign” to run your program.
If you did not follow these requirements, your tutor won’t be able to configure and run your software during marking, and your marks won’t be ready for discussion in Week 12 lab.
OO design requirements
- Define classes that are meaningful to the application. Inheritance relation should be considered.
- Define meaningful methods and instance variables in each class, such that the class can be reusable in similar projects.
- Separate the GUI classes from non-GUI classes (where the core functions are implemented) as much as possible.
javadoc comments
- Every public Java class should have a class header comment showing its main purpose, versions and authors (including the student IDs).
- Every public constructor and method should have a header comment indicating its purpose, pre- and post-conditions (if any), exceptions (if any), as well as the purpose of individual parameters and the return value.
Detailed Class Diagram
You are required to provide a detailed class diagram to show the OO design of your program. You must use software to draw it. Different UML tools use slightly different notations. It is ok that your chosen UML tool does not use the same notation as the lecture notes. This diagram will be used by your tutor to assess your OO design
