Reference no: EM133880400

Advanced Programming

Background Information
For this assessment you need to write a Java application with Graphic User Interface (GUI) which adheres to the object-oriented programming principles as specified in the specification of Assignment 1. In addition, you are required to practice on:
developing GUI applications using JavaFX.
implementing event driven programming.
storing persistent copy of data.
utilising advanced OO design patterns.

You are being assessed on your ability to write a program in an object-oriented manner. The following guidelines apply throughout this assessment:

Any collections of objects in your program should be stored properly.

Learning Outcomes
Demonstrate knowledge of basic OO concepts and structure design in Java programming.
Devise solutions to computing problems under specific requirements.
Encode the devised solutions into executable programs and test the programs.
Demonstrate understanding of coding conventions and ethical considerations in programming.
Design graphical user interface to enable intuitive user interactions.
Develop test cases to validate the design and the execution of the program.
Practice on basic design patterns.
Manage time properly.

Overview
In this assignment, you will build a GUI application for The Super Event booking system. The app sells event tickets as shown below. The app will be able to:
List all events.
Book an event with number of seats.
Checkout.
Display orders.
Export orders.
Advanced features (see details in Section 4).

Getting Started
Your program should be able to read data from a text file "events.dat" (provided). The content of the file is shown as below. Each row is a line in the file. Columns are separated by semi-colons ";". Each event has a title, a location and a day information showing when and where the event will be held. The price for a same performance may differ depends on the day and the location. The total tickets column is the maximum capacity of the venue. #Total minus #Sold is obviously the number of tickets remaining, e.g., the event in the first row of the following table has 68 (99 - 22) tickets remaining.

Task Specification

Basic functional requirements are listed below.

The application requires login with username and password. A wrong login (e.g. incorrect combination of username and password) should not be able to go further. Note, all users share one system. Hence when one user booked some seats for an event (after checkout), other users can see the reduction of available seats as well.

A new user can sign up. When signing up, the user should provide details including username, password, and a preferred name.

Each user is shown a dashboard after login. The dashboard should display a personalized welcoming message that addresses the user by preferred name. The dashboard also displays the events that are stored in the data. Note, you can assume there will never be no more than 15 events, e.g. you don't need a paginator to show events on multiple pages.

A user can book events by adding them into the cart. Your program allows the user to place an order by selecting an event and specifying the quantity. The program should allow the user to update the shopping cart (e.g., removing bookings, updating quantity) before checking out. When there is a modification to the cart, your program should verify the availability of tickets and notify the user if any selected event is fully booked.

Example 1. Assume that there are 10 seats of "Mozart Chamber Music" available on Monday (40 sold for Studio 1 which has 50 seats). A user will get a warning message if 11 seats were added into the cart.

Example 2. Assume that there are 10 seats of "Mozart Chamber Music" available on Monday. The user added 10 seats in the cart. Then the user further booked 2 more seats to the cart. A warning will be shown before checkout as there are no enough seats. Checkout will fail.

Example 3. Assume that there are 10 seats of "Mozart Chamber Music" available on Monday. The user booked 10 seats and checked out successfully. Then the user wanted to add 2 more seats for the same event. A warning will be shown and checkout cannot proceed.

A user can check out. If there is no problem, the user will be notified of the total price. Once confirmed by the user, proceed to payment, where a simple validation is performed to check:

a 6-digit confirmation code, which supposedly is sent to the user's phone or email (sending the confirmation code is not required in this assignment). The validation is considered successful, as long as a valid six-digital is entered, e.g. 230134, or 792466, but not 120.23 or ab1023 or 94784 or 1124985.

the booked event is at least today or later. Our simple system only works for one-week, starting from Monday. Hence if today is Monday, when we log into the app, we can book all events scheduled from Monday (Mon) to Sunday (Sun). If today is Wednesday, we can NOT book any events scheduled for Monday (Mon) and Tuesday (Tue). If today is Saturday, the only shows that we can book are Saturday (Sat) and Sunday (Sun) events.

A user can view all the orders. The user can view the following details of all historical orders: (1) a four-digit order numbers, starting from 0001, 0002, and so on; (2) date and time the order was placed;
(3) the event booked along with the number of seats; (4) the total price of each order. The orders should be displayed in reverse chronological order, with the most recent order appearing first.

A user can export all the orders to a text file, same as the above displayed content, including (1) the four-digit order number; (2) the date & time of the order; (3) the booked events with their quantities in that order, and (4) the total price of the order. A user can specify a preferred file name, and preferred location for saving the file to export.

A user can log out and exit the program gracefully. When login back again, the user (either the same or different) can see the ticket status just before the logout, meaning the system is persistent.

Advanced Tasks

Admin features: The extended version of your program supports a special user, the admin. The account is initialized by login with the special username and password: admin and Admin321:
The admin user can perform the following actions:
Once log in, the admin user should be welcomed with an admin dashboard.
The admin can view all events, same as what a normal user can view. However, the admin should not have a shopping cart. In addition, the same performance will be grouped together. That is, there is no repetition in titles. For example, the show "Jazz Night with Joe" at the Theatre Nova will only appear once but with two options: "Mon" and "Tue". The show "Mozart Chamber Music" will also appear once, but with three options: "Studio 1" - "Mon", "Concert Hall" - "Sat" and "Theatre Riverside" - "Thu".
The admin can disable one or multiple events. Once an event is disabled, normal users would not be able to see that event. Note the event is just disabled, NOT deleted. The admin can still enable the event later for normal users. Note, there is no need to check whether there are existing bookings for the to-be-disabled event, assuming refund is properly handled. Restoring a disabled event simply restores all the previous bookings.
The admin can update the list of events through GUI
add an event, providing the name, venue, day, price and venue capacity (ticket sell should be zero). Check for duplicates.
delete an event. Give warning but OK to proceed if there are existing bookings for the event.
modify an existing event, e.g. adjust the capacity of a venue, change the venue, the day and the price. Check for possible duplicates.
The admin can view the existing orders of all users.

User features:
The advanced version allows a normal user to change the password. Once password changed and application restarted, you application should accept the new password. Note, the new password should never be stored in its original text. Some kind of encryption should apply, e.g. simply shifting the alphabetic position, a -> d, b -> e, 1 -> 4 etc.

JUnit

You are required to write at least 5 test cases for the validation mentioned above, e.g. password validation, availability check, or existence check.