U-Fund: A New Page was my SWEN 261 team project. We built a full-stack system where incarcerated people could request books, prison administrators could approve or deny them, and outside helpers could fund approved requests. It was one of my first chances to work on a fairly complex application with several roles and workflows shared across a team.
Working as a team
This was a very fun project to work on because the four of us had to collaborate on both sides of a large system. The team was Michael Lizzio, Liam Pennino, Nina Sagawa, and Selene Shen. We divided features between the Angular interface and Spring Boot API, then had to make sure all of our work fit together.
It gave me real experience coordinating responsibilities, working with code written by other people, and building features that depended on another teammate's work. There was no AI involved in the project.
Three different roles
The system had three roles with different permissions and tasks. Inmates created profiles, requested books, and received notifications when a request was approved, denied, or funded. Administrators reviewed the request pool, managed accounts and prisons, and moved approved books into the public cupboard. Helpers searched that cupboard, added books to a funding basket, and completed a simulated checkout.
The main workflow connected all three roles. An inmate submitted a book request, an administrator reviewed it, and approval moved that book into the collection helpers could fund. Funding it then generated another notification for the inmate.
The workflow in the final demo
The final demo walks through the application from each role's point of view. A user could create an account as an inmate, helper, or administrator. Inmates requested books, administrators reviewed each request with an approval or denial message, and helpers browsed the approved books and added them to a funding basket.
Notifications connected the steps. The team added them as one of our feature enhancements so an inmate could see when an administrator approved a request and when a helper funded the book.
The shared entry screen supported login and account creation for each of the application's roles. 
Administrators reviewed each inmate request and could include a message with the decision. 
Approved requests became available to helpers in the book cupboard. 
The funding basket collected books from different inmates before the simulated checkout.
How we structured it
The backend followed a three-tier design with Spring controllers, DAO interfaces, file-backed DAO implementations, and model classes. Seven REST resources handled accounts, books, requests, funding baskets, notifications, prisons, and profiles. The Angular app had matching services and route guards for each user's role.
The backend stored its data in JSON files and rewrote those files when records changed. The project also included JUnit tests and separate JaCoCo coverage reports for the controller, model, and persistence tiers.
One complete interaction
This sequence diagram follows a helper searching for a book and adding it to a funding basket. The request travels from the Angular client through the Spring controller and service layer, then into the basket and book data objects before the result returns to the browser.
Testing and review
We used JUnit, manual browser testing, and curl requests while building the application. In the final presentation, the team reported at least 91 percent coverage in every backend tier and 100 percent branch coverage in the model tier.
We also ran SonarQube and discussed the issues it found instead of treating the report as a score. The presentation called out static fields changed from instance methods, unnecessary verbosity where Java's diamond operator could be used, and avoidable string concatenation as examples we would clean up next.