Singapore Sports School (SSP) Booking Application

Corporate pass booking application

Source Code

Skills: Java • Springboot • VueJS • Agile • MySQL

Coursework Project

7 min read


Introduction

This project was done as part of a course in SMU, IS442 Object-Oriented Programming, which is an SMU-X module, requiring students to ‘take on real-world changes by collaborating on projects with corporates, non-profit, and government organizations’. In the context of this module, Singapore Sports School (SSP) was the client sponsoring the projects within the module.

The main goal of the project is to build a system to facilitate the booking of corporate passes for staff in SSP, which allows staff / employees of SSP to visit attractions such as Art Science Museum, Singapore Flyer, Gardens by the Bay etc.

Requirements

As expected, we were required to use Java for our project since this is an object-oriented programming related module, as well as form groups of 5-6 members to complete the project together.

project members
Project mates for this module
User profiles and needs

The project requires 3 distinct groups of users with different access controls within the application, namely

  • Borrower : permanent employee of SSP who is able to loan a pass.
  • Administrator : someone who configures the application parameters, and may also be an employee of SSP (able to borrow passes)
  • General-office personnel (GOP) : responsible for issuance and collection of the loan pass card
home page
Application homepage / login

All 3 kinds of users need to be authenticated with username and password as well. Our group made use of JSON Web Tokens (JWT) and Spring Security to fulfill this requirement, allowing users to login and reset their passwords with time-sensitive tokens issued on request.

password reset
Password reset

There are certain requirements and verifications with regards to designing the Loan Pass entity, such as (not exhaustive)

  • Limiting to 2 passes per loan and 2 loans per month per user
  • Capturing the details of the borrower and the previous borrower
  • Confirmation email upon successful booking
  • Reminder to collect and return pass to General Office (GO)
  • Cancellation of booking with confirmation email
Analytics

There was also a requirement to allow administrators to see basic statistics / analytics within the applications such as:

  • Monthly statistics : number of loans per month, number of borrowers per month etc.
  • Number of loans per employee : monthly, bi-annual, annual timeframe
analytics dashboard
Admin analytics dashboard
Database design

Part of the project requirements also required us to use a relational database, and in this case, our team decided to go with what we were most familiar with (MySQL and JDBC), to minimise initial learning curve and start the project in a shorter time since we had to manage our time spent on this with other modules (and projects) at the same time.

project members
Initial UML diagram for our RDMS

The image may not be very clear, but our initial design was based off the Model-View-Controller (MVC) design pattern, grouping related application logic together in a controller.

Timeline

We split our team into frontend and backend, groups of 3 each. I was personally in the backend team, making use of Java, Springboot, and MySQL in the backend server application. The timeline is as such

  • Week 7 : Consolidate requirements and planning
  • Week 8 : Initial setup and researching for libraries to use
  • Week 9-10 : Frontend and backend initial mockup
  • Week 11-12 : Coding out features
  • Week 13 : Refactoring, clean-up and bug-catching
  • Week 14 : Submission and presentation

The team held alignment meetings every 1-2 weeks to go over what have been done, what is needed to be done, and resolving any potential blockers that may come up.

system overview
System overview of the application

Halfway through, we discovered a gap in our development process. All of us are students and we may not be working on the project at the same time, which became apparent when the frontend team posts a question regarding the backend services and APIs in the groupchat, which may be only answered a few hours later.

"How could we then minimize this process overhead and streamline our communications better?"

One of our group members, Kok Wee, suggested and then proceeded to implement a simple API documentation service with Swagger. This allowed the frontend teams to refer to should they have any questions about API services that needs to be immediately answered before they can proceed with development.

swagger ui
OpenAPI documentation with Swagger
Tech stack
Frontend libraries
booking ui
Booking UI
  • GridJS : Displaying tables and data
borrower management interface
Borrower management interface
  • ChartJS : Displaying analytics charts
  • QuillJS : Rich text editor for admin to configure email templates
rich text editor
Rich text editor for email templates (admin view)
Backend libraries
Learnings

This module was my first time properly learning object-oriented programming, as well as touching both Java and Springboot. While it was challenging, I can safely say that I took away many key concepts and learnings with regards to program design and code writing, as well as integrating both frontend and backend together to form a working prototype.

As the frontend was moving a lot faster than the backend (due to the learning curve of using Springboot and writing Java code for the first time for most of us), the backend had to catchup and write APIs for the frontend to use. Initially, we made the mistake of writing code that we ‘think’ might be useful, but would later end up being obsolete and not needed by the frontend team.

One of the greatest learnings was definitely to keep constant communication between both the frontend and backend, and writing code to suit the needs of one another.

Java and Springboot was also a lot more customizable and verbose, when compared to previous programming languages and frameworks that we have worked in the past. This was a big step out of our comfort zone and presented many challenges to us, but overall it was a great experience for the team, being able to experiment on new technologies and takeaway software development experience and best practices from this module / project.

Chew Yi Xin 2023  •  Last updated Feb 2024