Architecture Documentation - csepulveda7/SpotApp GitHub Wiki
Program Organization
System Context Diagram
Our system context diagram shows the relationship between our overall system and our users and the interactions between them. At the highest level, a user of our app would interact with it by using it to take pictures of dogs and view their dog collection. The Dog Classification System is what houses all of our software, such as our mobile application and the server we use to transfer data to/from that mobile app. Our database system will store all of the data that our app needs to show users, such as their account information and dog collection.
System Container Diagram
Our system container diagram gives a deeper look at our Dog Classification System and its inner containers. Our system hosts both our Spot mobile app and our backend server that works on classifying images as well as communicating with the database as well as our APIs, such as the Wikipedia API and the Petfinder API.
System Component Diagram
Our system component diagram takes the deepest look into our system by splitting it up into its most vital components. First we see the mobile app, which will allow users to interact with our dog classification system, hosted on our backend server. The mobile app will communicate to our server through API calls and interact with the appropriate controller for the task it is attempting to do. These controllers will then refer to their respective models in order to get/send the information necessary to follow through with the request. These models will then communicate with either the database system or our external APIs (Wikipedia & Petfinder) to get/send the information necessary, and then send it all back up to the mobile app for users to view.
| Component | User Stories ID |
|---|---|
| User Controller | 4 5 6 7 11 24 |
| Breeds Controller | 4 5 20 |
| Machine Learning Model | 15 16 |
| User Model | 4 5 6 7 |
| Breeds Model | 4 5 20 21 |
| Database System | 4 6 7 11 20 |
| Wikipedia API | 4 18 19 |
| PetFinder API | 4 22 23 |
Code Design (UML Diagram)
Our UML class diagram allows us to break down our code and how it will be designed to allow data to flow between different classes. Our main classes are for our screens and their respective features. These include login, signup, main page, camera, Pokedex/collection, account, and the breed page. Some of these classes extend others, and others use/share components between each other and their states.
| Class | User Stories ID |
|---|---|
| Splash Page | 0 1 |
| Login Page | 1 11 |
| Sign Up Page | 6 7 8 9 |
| Main Page | 11 12 |
| Pokedex | 19 |
| Account Page | 24 |
| Camera Popup | 13 14 15 |
| Breed Page | 18 |
| Confirm Breed Popup | 16 17 18 |
Data Design
Database ER Diagram
The 'Users' entity is the main entity that holds most of the information that users will reading/writing and interacting with on a regular basis. This entity will hold our user's name, email, profile picture, score, and a JSON of their collected breeds. The score will be read from the scores entity, which will be a list of all users' scores. We decided to store the scores this way to make it easier later down the line if we want to implement a social feature where we can see other users' scores and compare (leaderboard). The collected breeds entity will store all the breeds names and then refer to another JSON that will give a user's specific stats on that breed, such as whether or not they have 'collected' it yet, how many times they have collected it, and how many points that breed is worth.
Business Rules
Our app must uphold the expectations of a professional mobile app. This means that users expectations of an app should be met, such as being able to load into the application quickly, login and logout securely, being able to access different features quickly with minimal wait-time for their data, and most importantly feeling assured that the application is not being given access to restricted phone data or features (such as contact or messaging permissions). Other rules include encrypting user passwords, storing user information securely in a cloud database, not giving user's access to change restricted fields in the database, and making sure that any and all information provided to users on the app is as accurate as possible (ML predictions, user stats, breed info, etc.).
User Interface Design
Click here to try our prototype demo!
Our UI wireframe shows how the flow from screen to screen will work and how the users will be navigating through the app to get to and from features. There are multiple different routes throughout our app depending on what the user wants to do, however, we tried to keep our application at a minimum of 6 unique screens (not including popups) that can be easily navigatable in no more than 2 or 3 button clicks or swipes.
Splash
The very first screen users will see is our animated splash screen, which welcomes them to the app while it verifies where to route them to. If they are logged in already they will be routed to the main screen, if they are not logged in they will be sent to the login screen.
Login Screen
Our login screen will have a form where users can write their email and password to login into their account. If their login information is authenticated, they will be routed to the Main screen. Users can also navigate to the Registration screen to sign up for an account, and they can also reset their password by clicking on the 'Forgot Password?' link.
Registration Screen
Our registration screen will have a form that allows users to create a new account after they provide the necessary information, such as their email address, name, password, and confirming their password. Once a user has filled out the form, they can click on 'Sign Up' to attempt to register their new account. If they remember or are alerted that they already have an account, they can click on the 'Log in here' button to go back to the Login screen.
Email Verification Pop-up
Once users have clicked 'Sign Up' in the Registration screen, if their account creation is successful, they will be routed back to the Login screen but will be shown a popup modal telling them to verify their account through an automated email that they will receive. They can dismiss this alert by pressing 'Continue', and will not be allowed to log in until they verify their account.
Main Screen (Camera)
Once a user's account is verified and they log in, they will be sent to the Main screen. This screen is the central hub of the entire app. Users can take pictures straight from this screen since the camera is open at all times here (similar to Snapchat). They can also see what their current score is on the top left, navigate to their collection by tapping the button on the bottom left, or navigate to their account by tapping the button on the bottom right.
Camera (After Picture Taken)
If a user takes a picture of a dog, they will see a popup modal that indicates whether or not a breed has been spotted in their picture. If their is a dog in the picture, they will be notified of the breed of the dog and shown a picture of that breed, they will then be given the option to add the dog to their collection or retake the picture.
If the dog in the picture is a 'new breed', meaning they do not have the dog in their collection, it will alert them that a 'New Breed' was 'Spotted'. Lastly, if there is no dog in the picture, they will be notified that they must retake the picture because no dog was detected.
Collection Screen
The collection screen will allow users to swipe through all of the available dog breeds to collect and highlight the ones that they have already spotted. For breeds that users have spotted, it will show a picture of that breed and allow them to press on the name of the breed and navigate to the Breed Info screen.
Breed Info Screen
The breed information screen will allow users to do 3 separate things. They will be able to see a gallery-like view of the different pictures they have of this breed, they will also be able to read important information about the breed from their Wikipedia page. Lastly, they will be able to see if there are any nearby shelters that have that breed available for adoption (through the PetFinder API).
Nearby Shelters Feature
Again, the nearby shelters feature will display a list of any animal shelters or adoption centers near the user's location that have that specific dog breed available for adoption. If time permits, we will also like to show the user's an actual 'map view' where they can see the actual geo-location of these shelters in relation to their location, and how many of that breed are available in each location.
User Account Screen
A user's account screen will show their profile picture and allow them to change their picture. It will also show any important stats about their dog collecting, such as how many dogs they have spotted in total, how many unique breeds they have collected, how many points they have, etc.
| Screens | User Stories ID |
|---|---|
| Splash Page | 0 1 |
| Login Page | 1 11 |
| Registration Page | 6 7 8 |
| Email Verification | 9 |
| Main Page | 11 12 |
| Camera Popup | 13 14 15 16 17 18 |
| Collection | 19 |
| Breed Info Screen | 18 |
| Nearby Shelters | 14 |
| Account Page | 24 |
Resource Management
For resource management, we do not believe there will be issues. The app will be using external APIs and an online database, so the large parts of the computation will not be native on the device. As a result, there will not be a large amount of memory required at a given point. We will also not be running database requests and the backend machine learning model at the same time, so the processing power should be relatively small.
Security
This project is fairly secure since any sensitive data being used is stored on a database, which uses encrypted data. Nothing will be stored locally on the app, so sensitive data is stored securely. For signing in, the credentials will be sent directly to the database for authentication and to the database for generating new users.
Performance
Since the app is not using a large number of resources, the client-side part of the app should perform well. Any performance issues will come from server-side computations. Even so, the computations running should be efficient and optimized for performance.
Scalability
Since this app is targeted towards a large audience, we can anticipate a large number of people could potentially use it. The app uses a database to handle user information, which is already optimized for a large number of users. The same can be said about the pictures to be stored for each user. The server will be able to handle a large number of requests as well, which allows for scalability. The entire app is based on a user and the data being saved and pulled from a database, so as long as there is room for more users, the app should be able to handle it.
Interoperability
This system will not be sharing any device resources with any other hardware or software. The app should be a fully closed system regarding resources. The app will use a backend server, database, and client; nothing else.
Internationalization/Localization
Everything will be in English.
Input/Output
For I/O, the input is a picture. The output is the processing behind the scenes and the user being able to see their data such as score (based on what breeds they've seen), how many breeds they've seen, and how many dogs they have seen in total. This may also include the "memories" where you can see all the photos you have taken up to a certain point.
Error Processing
Being that the only error that can occur based off of user input is the machine learning model not being able to detect what breed dog it is. In this case, you are prompted with a modal that tells you that the breed wasn't detected. The rest of the error handling would have to do with the database, as the input is strictly based off of photos that the user takes.
Fault Tolerance
The fault tolerance is low; we rely on Microsoft's Fetch! Machine Learning Model which is extremely reliable.
Architectural Feasibility
Our architectural is generally very feasible. The system works similar to other camera apps on the market that store photos on a database. Being that ours relies on fetching the photos and data from this database, it makes the entire product much easier to manage.
Overengineering
Our app is very simple and straightforward and the only over-engineering we are worried about is the chance of maybe someone scanning a cat, monkey, or some other arbituary animal that isn't a dog. Even so, Microsoft's Fetch! Machine Learning Model is out of the box a very reliable model. That is the only input necessary, so the rest just has to do with storing that information and then processing it.
Build-vs-Buy Decisions
We aren't spending any money, most of the app is built by the ground up. We are using React-Native, React-Native-Elements, and maybe some other small libraries for basic components. This will save us time that we could dedicate to more important features on the application.
Reuse
We are relying on preexisting software; the information about the dogs and the local shelters will be pulled from an API and the machine learning learning model. All of which are well supported, especially Fetch! which was made by a large company, Microsoft, that is very reliable.
Change Strategy
Everyone here is new to the team they are working on so we are developing a strategy to build general concepts for the future and then meet as a team to discuss ways to narrow down each part as we get to it. This allows for us to not have to pour time in to extraneous concepts without being able to modify everything later on down the line.
Extra System Diagram (Including Libraries)
