Java & Swing GUI

Our project is a food reviewing program which allows the user to view affiliated restaurants and their individual dishes, including price, rating, and description. The Program allows users to document their tried dishes and experiences through reviews, acquiring points for their profile, and compete with other users for a higher score. Restaurants can upload their menus and see diners' experience with their restaurant.

Digital Dining dash is entirely written in Java, and utilizes the Swing API for graphics. This project was initially collaborative (see the github repo to view its editing history, and all the fabulous additions by my fellow group members!), however it was unfortunately very much unfinished and buggy by the time it was submitted, so I worked on it afterwards to fix it up. The focus of this project was primarily clean architecture (CA), which is a design philosophy developed by Uncle Bob to organize code in a way that separates their responsibilities. My group members and I seemed to struggle to grasp the concepts of CA at first, but as I now continue to add on to the project, it is pretty straightforward (albeit bulky)!

   If you are to look through the code, you'll find that there are around 2 interfaces, and a handful of classes associated with each use case of the application. The purpose of this is to add layers of separation, effectively splittng the front-end from the back-end. The entity layer of the program (being users, restaurants, and dishes) are stored using serialization, so that data is fetched through a model rather than the entity directly. Graphical content is fetched from "response models". Controllers modulate behaviour between data access and the "presenting classes" (the presenting classes being those that instantiate GUI stuff) by use of interactor classes. This arrangement makes it quite easy for an entity to be updated through the entire program, all the way to where it is stored, with each action taken by a user. Updates may include favouriting a restaurant, an owner editing their restaurant, or a user editing their profile.

Here are some hypothetical interactions with the program that helped our group decide how to decompose the scope of our project into use cases:

Restaurant feedback

Abdelrazak is a restaurant owner who wants to open a new location that is too small to offer all the available plates in his main location. He opens his restaurant page and sorts the plates offered by review and picks the most preferred meals to be in his new location.

User Writes Reviews for their Favourite Restaurant

A frequenter of a Torontonian Michelin-Star restaurant has enjoyed eating at the establishment so much that theu want to share their positive experience with a community online. They remember that they have an account with Digital Dining Divas which does exactly that, so they log into the program with their username and password. They leave glowing reviews and 5 stars for all the dishes they have tried there.

User creates account and uploads pictures

Taylor view his friend's profiles and notices you can post pictures. He chooses a unique username And password and creates an account. He posts pictures to his profile and he links those pictures to the restaurant and the dishes he had.

For future developments, Digital Dining Divas can incorporate a flagging system to be able to restrict inappropriate, irrelevant, and malicious content. This would of course be permissable by specific agents such as restaurant owners and/or the administrators of the site. Further, this application can have a data analytics page accessible by the administrator. I also think it would be beneficial to incorporate a database-driven design, maybe with MYSQL, as there is a constant influx and efflux of data throughout the usage of this program.