Java Fundamentals End Assignment

Inholland University of Applied Sciences

Teachers: Mark de Haan & Annemarie Burger
Submission deadline: Before the exam

Introduction
In order to complete the course of Java Fundamentals students need to complete two tasks:

1. An end assignment, consisting of 4 parts that result in one application.

2. A classroom exam session, extending the functionality of the end assignment with three new
features.

The document before you details the requirements for this end assignment.

General requirements:
• Unless otherwise specified, requirements are must-have for a passing grade.
• The application must be written in JavaFX.
• The application must be submitted as a zip (not .rar, .7z, or other formats) file containing the
following:
o /src – directory
o pom.xml
o Readme.md
• The name of your zip file must be: [your-name]-[your-student-number]-[end-assignment].zip,
e.g. wim-wiltenburg-123456-end-assignment.zip
• Code quality will be reviewed:
o Java coding conventions are followed.
o Code is written concisely and clear: methods are short (no 30+ line methods). Names
are chosen well and without spelling mistakes. Should someone other than you read
the code, they should be able to understand it easily.
o Object Oriented Principles are used: Encapsulation, inheritance and polymorphism
are used to hide class implementation details and prevent duplicate code. Static
variables/objects are not used.
o Code is robust: Input validation and exception handling are implemented wherever
needed to handle possible edge cases.
o All code is formatted properly and does not contain any profanity.
• Your application must be able to start up in the IDE of the reviewer (IntelliJ 2024.2, Java 21
LTS)
• The screenshots in this document are indicative. Feel free to arrange and design it to your
own taste, as long as the required functionality is there.
• If you have specific usernames/password that are needed to log into the application, please
share them in a README.md file in the root of the project.
• Before creating your zip file, do a code reformatting on all your files, and optimize your
imports!

1
Objectives
Your task is to build an application for a small movie theater. The users of the application will be able
sell tickets. It will also be possible to manage the showings, and to view the history of ticket sales.

The application consists of the following functionalities:

• Login
• Greeting of the user, including displaying their role
• Ticket sales, including seat selection
• Showing management
• Viewing sales history

The login screen should be a separate window. The other functionalities should all be usable in one
main window.

• It is allowed to use separate modal dialogs for adding and editing the individual showings or
displaying confirmation of a sale. The choice to use separate dialogs or the main window is
up to you.
• Do not use pop-up windows (message- or dialog boxes) to display error messages.

Database object
The data in the application is maintained by a database object (not a real database) and is initialized
at startup.

Important: For learning purposes, the data is not allowed to be static, and therefore the Singleton
Pattern must NOT be used. Populate the database object with initial data.

Make sure to provide usernames & passwords in your README.md.

User experience
The example screen designs in this document are just an indication of what the UI could look like.
The screen design is up to you, as long as a similar (or better) level of usability is achieved.

2
Assignment part 1 - Login Screen
Roles: All

The login screen is a basic screen with username and password. You need to have a proper
mechanism in place to validate the input and grant the user access to the application.

First, make sure you have an in-memory database class that contains a collection of users. Initialize at
least 2 example users with different roles in the constructor of your database class.

Then develop a window that allows users to login using the usernames and passwords stored in the
collection. When the application starts, this window should be displayed.

An example of what the window could look like:

After clicking the ‘Login’ button with a correct username and password combination, the login
window should close and a new main window should open.

The user must get a clear and descriptive message if something goes wrong during the login process.
An example is to display: ‘Invalid username/password combination’ instead of ‘Login failed’. Note
that, as per the general requirements listed before, a pop-up dialog should not be used to display the
error message.

Once the user is logged in, the main window is shown. The name and role of the logged in user are
visible. The dashboard should also display the current date and time.

The application should only display or enable the navigation buttons that are applicable to the role of
the logged in user. In this document, all buttons are always displayed.

3
Assignment part 2 – Management
Roles: Management

When the user opens the ‘Manage showings’ part of the application, a view should be displayed that
allows the user to manage movie showings.

This screen provides standard CRUD (Create, Read, Update, Delete) functionality for showings.

The ‘Edit showing’ and ‘Delete showing’ should only be enabled when a showing is selected. The
‘Delete showing’ button should not delete the showing, but instead display an error message if
tickets have already been sold for the selected showing.

Ensure that when the showing collection is modified, the changes are displayed immediately. The
user should not have to click buttons or restart the application to see the changes.

4
The user interface for adding and showings should work intuitively and fast. It is up to you to decide
if you wish to use a modal dialog, or a view in the main window. The following aspects are considered
important:

1. It should be possible to fill out the form using only the keyboard (so consider the tab order,
and giving the first input field focus when the view opens. Also the dates and times should
support a date/time picker, but not require it.

2. Ensure the users knows in what format to enter the data (especially important for date
fields) and provide validation in case a mistake is made.

3. It should not be necessary to enter ‘obvious’ data. For example, when editing a showing, the
title, start and end dates and times should already be filled in with the existing data. When
creating a showing, after entering the start date, the end date can be given the same value as
this will usually be the correct date. You could also use a ‘Duration (including break)’ field
and automatically calculate the end date & time based on the entered value.

An example screenshot is given below, but you are encouraged to come up with a better solution

5
Assignment part 3 – Sales
Roles: Sales

When the user opens the ‘Sell tickets’ part of the application, a view should be displayed that allows
the user to select a showing.

Note that this view should display all upcoming showings. It should not display showings that have a
start date/time in the past. The showings should be ordered by their start date/time.

The number of seats left should be calculated based on the sales information in the database.

The ‘Select seat(s)’ button should only be enabled if one showing is selected. Clicking the button will
allow the user to select the seats:

6
The ‘Sell tickets’ button should display the number of seats selected. It should only be enabled if the
user has selected one or more seats, and has entered a customer name.

Clicking the ‘Sell tickets’ button should create a new ticket sale in the database and then navigate the
user back to the showing selection screen.

The cancel button should navigate the user back to the showing selection screen without creating a
ticket sale.

7
Assignment part 4a – Sales history
Roles: Management

When the user opens the ‘View sales history’ part of the application, a view should be displayed that
shows all created sales.

Assignment part 4b – Serialization

Roles: All

When closing the application, the state of the database (the collections of showings and ticket sales)
should be serialized to a binary file.

When starting the application, the file should be deserialized. This ensures changes will persist
throughout application restarts. Make sure the application does not crash when the serialized file is
missing.