Java Banking System

This is a high-level Java program that simulates the bank account of a college student over the course of one year starting in August of the current year and ending in July of the following year.

Methodology

The specification required students to implement multiple producer and consumer threads that interact with a single bank account. Those threads are instantiated as instances of the Runnable class which extend the JavaBank parent class. They are not directly implemented as threads from Java’s thread class because it does not allow for the inheritance of other classes. Since the concurrent execution of multiple threads and their interactions with the same account (implemented as variable) are required, the Runnable class was the most suitable option for development.

There are 3 main aspects of the simulation:

1. Parent Class (JavaBank)
2. Consumer Threads (Housing & Meal Plan, Tuition, and Random Events)
3. Producer Threads (Family Funding, Financial Aid, Paychecks, and Random Events)

Limitations

Given the scale of this simulation, it is understood that not all microtransactions and real-life scenarios can be reflected in the system. Many real-life financial situations are taken into account and many are implemented, but not all are included. In addition, not all students manage their finances in the way that the one in this specific simulation does. For the a median depiction of a student’s financial journey throughout the year, the simulation models the interactions of a working, middle-class student dealing with the costs of attending an average higher learning institution.

Design

Timeline

In regards to the timeline, the year starts at the beginning of August of the current year and concludes at the end of July of the following year. This timeline is specifically chosen for the implementation because it most accurately reflects the start of the academic year. Furthermore, each day of the year corresponds to a specific second in the program. This is done as a way to better understand how and when each thread is being handled throughout the program’s execution. To achieve this, the execution of all threads were offset by one second to ensure that they all coincided with the timer instantiated in the parent class.

Month	Reality Time Frame	Simulation Time Frame
August	Aug 1 - 31	1 - 31
September	Sept 1 - 30	32 - 61
October	Oct 1 - 31	62 - 92
November	Nov 1 - 30	93 - 122
December	Dec 1 - 31	123 - 153
January	Jan 1 - 31	154 - 184
February	Feb 1 - 28	185 - 212
March	Mar 1 - 31	213 - 243
April	Apr 1 - 30	244 - 273
May	May 1 - 31	274 - 304
June	Jun 1 - 30	305 - 334
July	Jul 1 - 31	335 - 365

Semaphore Components

Given that this implementation requires about seven concurrent threads, two semaphores are used to regulate the access to the programs “critical sections” (the debit account balance and the borrowed credit account balance). Only the acquire and release semaphore primitives are used to ensure that a deadlock, indefinite postponement, or overdraft of the debit account and credit card are avoided.

access_bal(1, true) Semaphore that allows or block threads requesting access (on the basis of available permits) to the student’s debit account.The first argument is 1 to initialize the number of available permits upon booting of the program. The second argument gives access to threads requesting admission into the critical section on a first-come-first-serve basis.

• access_bal.acquire() Thread request for access to the critical section (account debit balance).
• access_bal.release() Thread releasing the hold it has on the permit which allows entrance into the critical section.

access_credit(1, true) Semaphore that allows or block threads requesting access (on the basis of available permits) to the student’s borrowed credit account. The first argument is 1 to initialize the number of available permits upon booting of the program. The second argument gives access to threads requesting admission into the critical section on a first-come-first-serve basis.

• access_credit.acquire() Thread request for access to the critical section (borrowed credit balance).
• access_credit.release() Thread releasing the hold it has on the permit which allows entrance into the critical section.

Classes and Object Modules

Class	Description
JavaBank	The parent class of the Java automated banking system which instantiates all threads, declares and initializes all shared variables, and semaphores (borrowed cash credit balance and debit balance) used throughout the program.
FamilyFunding_PThread	Producer thread that uses the debit account semaphore to deposit funds from the student’s parents into the student’s account on the 17th of every month.
FinAid_PThread	Thread that uses the debit account semaphore to directly deposit financial aid refund into student’s account and the beginning of the Fall semester. As required by the original specification, the funds for the entirety of the academic year are deposited into the student’s account.
RandomEvents_PThread	Producer thread that uses the debit account semaphore to deposit funds of random nature into the student’s account. Random occurrences include periodic tips from work, money from special events (e.g., birthdays and holidays), and extra money from parents to assist with living expenses.
PayCheck_PThread	Producer thread that uses the debit account semaphore to deposit funds into the student’s account on a bi-monthly basis. All deposits made using this thread are made consistently every 14 days.
HousingMealPlan_CThread	Consumer thread that uses the debit account semaphore to remove funds from the student’s account on a monthly basis. Funds for semester meal plans and housing are removed from the debit account. In addition, the borrow account balance semaphore is also acquired for the payment of the credit card bill at the beginning of the month.
RandomEvents_CThread	Consumer thread that uses the borrowed credit account semaphore to increase the amount borrowed for the month. Random events are put on credit because the purchases made in that way were higher than normal charges to the account. The charges were made to the credit account so as to not overdraft on the debit account.
Tuition_CThread	Consumer thread that uses the debit account semaphore to remove funds from the student’s account on a semester-basis. All tuition charges were made roughly on the first day of the Fall, Winter, and Summer semesters, respectively. Charges include tuition, books, and other fees.