Cretaceous Gardens Controller

Language: Java

Introduction

Jurassic Park inspires the Cretaceous Gardens Controller(CGC) system/application. I am incredibly proud of this project. Out of all the school projects I needed to code, this took the MOST work. It was for a Software Development course at UNM. The class taught me a lot. Up to this point during my school career, I had made some pretty big projects, but these projects were pre-designed. I was building something based on a spec sheet. This project was very different. This course was all about building software from beginning to end, which included mostly design. We were given an overall idea, and we needed to design a solution and then implement the solution. This project required a group of five people to work together. This requirement added additional complexities to the project that I believe has been a necessary experience for me to grow. The idea was to build an entire system to control the Cretaceous Gardens.

Design Documents

We began our journey building this program by writing a Technical Feasibility Study(TFS) document. In this document, we take given logistical constraints provided by our "investors." For example, some constraints were. The payment system is all automated, and the cars are all self-driving, and they will pick up customers and bring them to the T-Rex exhibit. We also identified our constraints. These include constraints like the surveillance cameras must have redundant uplinks. Every node in the system must have a normal and emergency mode that responds to different protocols, and all Alarms must be audible in every part of the island. There must be non-audible alarms as well. This document determines if the project is even technically feasible.

The next document we built was the Requirements Definition Document (RDD). The purpose of this document was to define the requirements to create the CGC. We determined several objectives we wanted our system to have. These included safety, positive user experience, maintainability, and efficiency. We defined every hardware and interface we would need for the CGC. This includes a pay kiosk, car, and electric fence enclosure. We also defined the capabilities of the system. These include the emergency features, the safety features, and financial analytics.

The next document we made was the Software Requirements Specification(SRS). This document starts to get into more details of what is needed from a lower level in the software. What are the functions of each individual smaller component? What data do these components receive, and what do they send? Here we are defining the methods and behaviors of these pieces. The last part of this document describes different use cases and scenarios.

The last document we wrote was the Software Architecture Design(SAD. This document has class diagrams and the implementation plan. This is document breathes life into every component from a software perspective. It shows which components run on their own thread, what physical hardware pieces that component controls, and how each component communicates with each other and the root node, which is the CGC.

Software Overview

The final piece is to build the actual software. We followed our documents exclusively. This helped guide us in a lot of our programming as we already spent a lot of time of these decisions. The application was HUGE. It was one of the biggest programs I have made. Since we did not have to build this for a real park, we simulated everything's behavior. The video above shows what the interface would look like on a monitor system that would be used by an employee to monitor the park.

We can see at the bottom of a video the entrance to the park. There are pay station kiosks that a visitor would walk up to and buy a "token." This token acts as a ticket to the park, but it also has a GPS and a screen with instructions in case of an emergency. The purple dots are employees walking around with unique employee-only tokens. The green dots are visitors. We see them spawn from the pay kiosks as would happen with a newly purchased token.

When the visitors are ready to see the main attraction, they will go to a loading zone where a self-driving car will pick them up and then drop them off at the T-Rex exhibit. We also see helicopter icons that are constantly patrolling the park for safety. The "View Health" will toggle the health that all nodes are reporting. The "View Finances" button will change the GUI to showcase the current finances of the park. The last buttons will toggle the emergency protocol. This allows us to simulate the park's behaviors in case there is an emergency triggered for any reason.

This is the project. Please feel free to browse the GitHub repo if you would like to test out and run the application. I have also included the PDF to each document mentioned above. The links to all of these are directly under the video above.