Design Document

This is a design document for an Android app 'I'm pine thank you'

Document History

• Version 1.0
• Version 1.1
  • Update user story in acceptance test so that each feature has a singular, focused user story and that the accompanying acceptance criteria are detailed and specific.
  • Revise the current class diagram to enhance its logical structure and improve visual clarity.
  • Modify the wireframe to highlight the directional flow between screens, ensuring the user's journey through the application is intuitive and clear.
  • Minor changes in machine learning model and testing strategy
• Version 1.2
  • Edit system architecture with a newly adapted architecture (Firebase for Authserver and model serve from the client).
  • Include details on prediction model testing (error metrics used, performance testing).
  • Slightly revised the testing framework.
• Version 1.3
  • Revised user stories.
  • Modified wireframe
  • Modified frontend UI design details to match our change in scope
• Version 1.4 (Latest)
  • Modified class diagram
  • Added specific implementation details for our prediction model
  • Modified friends use case
  • Added Open Weather API feature
  • Added some design patterns that we used
  • Added brief overview of our testing method
  • Update datamodel diagram
  • Update API parameters and name

System Design

System Architecture

Class Diagram

Class used for each page

Class used for API calls and data manxfagement

Backend Data Model

Implementation Detail

• App
  Android app 'I'm pine thank you' is developed with JAVA.

  ---

  Android API Version: 34
  Java Version : 11

  ---

• Server
  The server used Django-Rest-Framework (DRF) to power rest-API server and it is hosted on an AWS EC2 instance, offering scalability and reliability.

• Database
  Data is securely stored in an AWS RDS MySQL database, seamlessly integrated with our server.

• Weather API
  Open Weather API for default values in prediction model.

Machine Learning Model

1. Naive Data Analysis
   • Utilizing linear regression to determine the approximate correlation between input and output.
   • Conducting correlation analysis to figure out the relationships among input variables.

2. Stationarity
   • ADF test for testing stationarity and employ differencing methods to make data stationary for training.

3. Prediction Model
   • Building prediction models by splitting data into train and test sets (90:10 ratio)
   • Utilizing the VAR mode and VARIMA model for predictions.

4. Model Enhancement : Data Augmentation and Variable Reduction using Granger-Causality test

Scaling

Jittering

Magnitude Warping

Results: Much more accurate model

5. Model Accuracy Assessment

   • Evaluating the accuracy of the prediction model through error metrics.

   • Checking for overfitting.

   • Comparing VAR and VARIMA with different number of variables.

   • Following is the comparison result:

Prediction Model Evaluation

Test Environment Setup:

• Isolate the test environment with all necessary libraries for VAR and VARIMA model execution.

Data Preparation:

• Clean the dataset to handle missing values and outliers.

Testing Phases:

Phase 1: Accuracy Testing

• Compare model predictions with actual historical outcomes using SMAPE (Symmetric Mean Absolute Percentage Error) and RMSE (Root Mean Square Error) metrics.

  • SMAPE is an accuracy measure based on percentage errors. It is defined as the average of the absolute differences between the predicted and actual values, divided by the average of the actual values, giving a percentage that describes the error size relative to the actual value. This metric is useful for comparative forecasting as it is scale-independent.

  • RMSE measures the square root of the average of the squares of the errors. This metric emphasizes larger errors and is useful when large errors are particularly undesirable.

Phase 2: Performance Testing

• Analyze time series for stationarity and perform model fitting.
• Conduct residual analysis to ensure residuals resemble white noise.

Phase 3: Scenario Testing

• Test models under varied weather scenarios to evaluate forecast reliability.

Phase 4: Robustness Testing

• Perform sensitivity analysis to assess model response to input variations.
• Apply stress testing by evaluating model performance with large data volumes.

Phase 5: Model Comparisons

• Compare the performance with 5 variables against 6 variables using the predetermined error metrics.

API List

User Group

Endpoint	HTTP Method	Description	Request Parameters	Response Status Codes	Response Body
/api/user/signin	POST	Signin	id, name, email	201 Created 400 Bad Request	User object
/api/user/{id}	GET	Get a user by ID		200 OK 400 Bad Request	User object
/api/user	PUT	Update a user		200 OK 400 Bad Request	Updated user object
/api/user	DELETE	Delete a user		204 No Content 404 Not Found	N/A

Plant Group

Endpoint	HTTP Method	Description	Request Parameters	Response Status Codes	Response Body
/api/plant/user/{user_id}	GET	Get a list of user's plants		200 OK 404 Not Found	List of plant objects
/api/plant/{plant_id}	GET	Get a plant by ID		200 OK 404 Not Found	Plant object
/api/plant	POST	Create a new plant	Plant data (JSON)	201 Created 400 Bad Request	Created plant object
/api/plant	PUT	Update a plant	plant_id Plant data (JSON)	200 OK 404 Not Found	Updated plant object
/api/plant	DELETE	Delete a plant	plant_id	204 No Content 404 Not Found	N/A

Diary Group

Endpoint	HTTP Method	Description	Request Parameters	Response Status Codes	Response Body
/api/diary/user/{user_id}	GET	Get user's diaries		200 OK 404 Not Found	List of diary objects
/api/diary/{diary_id}	GET	Get a diary by ID		200 OK 404 Not Found	Post object
/api/diary	POST	Create a new diary	Diary data (JSON)	201 Created 400 Bad Request	Created post object
/api/diary	PUT	Update the diary	Diary ID, Diary data (JSON)	200 OK 404 Not Found	Updated post object
/api/diary	DELETE	Delete the diary	Diary ID	204 No Content 404 Not Found	N/A

Follow Group

Endpoint	HTTP Method	Description	Request Parameters	Response Status Codes	Response Body
/api/follows	GET	Get users the user is following		200 OK 404 Not Found	List of users
/api/follows	POST	Follow a user	Target User ID	201 Created 400 Bad Request	Created follow object
/api/follows	DELETE	Unfollow the user	Target User ID	204 No Content 404 Not Found	N/A

Disease Predict Group

Endpoint	HTTP Method	Description	Request Parameters	Response Status Codes	Response Body
/api/disease	POST	Calculate disease probability	T_mean(float) Wind_speed(float) Rain(float) Humidity(float) Cloud(float)	200 OK, 400 Bad Request	Probability of disease (%)

Frontend Design

Log in/Sign up

1. Log in Page

• Log in (for the registered user only).

• If the user inputs the valid “id”, “password’ and clicks on “Login” button, the user is redirected to the home page.

• For new users, clicking on the “Create Account” button will redirect them to the Sign Up Page. 2. Sign up Page

• Sign up.

• If the user inputs “name”, “id”, “password”, “password confirm”, and clicks on the “Sign Up” button, the user is redirected to the Login page.

3. Tutorial Page

• A few pages to introduce new users to the app's features.

Home

1. Home/Main Page

• Manage pineapple avatar, farm view, user information, settings, and editing.
• If the user clicks on the edit icon, the user can edit pineapple details.
• If the user clicks on the "Diary" icon(pineapple icon), the user is redirected to the Pineapple Diary Page, and can write a new diary, view the existing diary list, view/edit the selected diary.
• If the user clicks on the “Prediction Model” icon, the user can input necessary data to predict pineapple disease and view prediction results & recommendations.
• If the user clicks on the “Friends” icon, the user can view the friend list, search for new friends and send friend requests, view the friend home page and their diaries.

2. Edit Page

• The user can edit pineapple details.

Pineapple Diaries

1. New Diary Page

• The user can input title, date, category etc to write a new diary. If the user clicks on the “Save” button, the new diary is added to the Pineapple Diary List.

2. Pineapple Diary List Page

• The user can view the existing Pineapple Diary List.
• If the user clicks on the + icon, the user is redirected to the New Diary Page, and can write a new diary.
• If the user clicks on one of the diaries in the list, the user is redirected to the Diary Detail page, and can view the clicked diary in detail.

3. Diary Detail page

• The user can view the previously clicked Pineapple Diary, including its title, date, category etc.
• Editing the information is enabled, and clicking on the “Save” button will reflect the changes.

Prediction Model

1. Input Page

• The user can input weather data to predict pineapple disease.
• If the user clicks on the “Submit” button, the user is redirected to the Output Result Page, and can view prediction results & recommendations.

2. Output Result Page

• The user can view brief pineapple disease prediction results & tips based on the imputed data from the Input Page.

Friends

1. Friend list Page

• The user can view the friend list.
• If the user clicks on one of the friends in the list, the user is redirected to the Friends Pineapple Page and can view the friend’s pineapple picture, avatar and and pine diaries.
• If the user clicks on “Search” and searches friend, the user is redirected follow/search friends page and can add friends.

2. Follow/Search Friend Page

• The user can search with the username, and the relevant user list appears as the search result.
• If the user clicks on one of the follow friend icons that user is added to the Friend list Page.

3. Friends Pineapple Page

• The user can view the friend’s pineapple details and diaries
• If the user clicks on one of the friend’s diary lists, the user is redirected to the Friends Diary Detail Page and can view that diary in detail.

WireFrame

Adding it all up

Design Patterns Used

Builder Pattern

The Builder Pattern is a creational design pattern that allows for the construction of complex objects step by step. This pattern is particularly useful when an object must be created with many optional and required parameters. It helps in enhancing the readability and maintainability of code, especially when dealing with objects that contain numerous attributes.

Key Features:

• Separation of Construction and Representation: The Builder pattern separates the construction of a complex object from its representation, allowing the same construction process to create different representations.
• Immutability: Often used to build immutable objects since all necessary parameters are available at the point of object creation. Fluent Interface: Builders frequently employ a fluent API, making client code more readable.

Purpose and Application in Our Project:
In our code, the Diary class uses the Builder pattern. This is evident in the inner static Builder class within the Diary class.

• Complex Object Creation: A Diary object has various attributes like title, content, category, privacy status, etc. Using the Builder pattern allows for a clear and concise way of creating a Diary object with specific attributes set and others left as defaults.
• Enhanced Readability: The Builder pattern makes the client code that creates a Diary instance more readable and easier to understand.
• Maintainability: When new fields are added to the Diary class in the future, the Builder can be easily extended without affecting existing client code.

 

Observer Pattern

The Observer Pattern is a behavioral design pattern that defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. It's often used for implementing distributed event handling systems and is crucial in the Model-View-Controller (MVC) architectural pattern.

Key Features:

• Decoupling: The Observer pattern promotes loose coupling between the subject (observable) and its observers. Real-time Updates: It allows for real-time notification and updates to multiple observer objects when a subject changes its state.

Purpose and Application in Our Project:
In our code, the DiaryData class and DiaryObserver interface employ the Observer pattern.

• Notification System: Whenever a Diary is added or modified (setDiaries), all registered observers are notified. This is particularly useful in scenarios where different parts of the system (like UI components) need to be updated in response to changes in diary data.
• Scalability and Flexibility: As the application grows, more observers can be easily added or removed at runtime, thus making the system more scalable and flexible.
• Separation of Concerns: The Observer pattern helps in separating the core or business logic of the application from the user interface. The DiaryData class does not need to know about the specific implementation of its observers.

Testing Plan

Acceptance Testing

1. Login, Sign-up, and Onboarding Tutorial

User Story:

As a new user, I want to sign up, log in, and be guided through a tutorial so I can understand how to grow pineapples and make an account of my pineapple plant.

Acceptance Criteria

1. Given I am on the sign-up page, I must be required to input all the fields: username, email (in the correct format), password, and password confirmation.
2. Given I am on the sign-up page, when I input an email that is already registered, I should receive an error message indicating that the email is already taken.
3. Given I am on the sign-up page, I should ensure that the passwords I enter are longer than 6 characters and that the password and confirmation match.
4. Given I am on the login page, I must be required to input all the fields: username, email, password and password confirmation.

2. Tutorial and Home Page

User Story:

As a user, I want to have a seamless onboarding experience when I first sign up for the app, which includes a tutorial and a personalized pineapple plant profile. Additionally, I want to be able to choose an avatar for a fun and personalized touch.

Acceptance Criteria:

1. Given it's my first time logging in after signing up, when I access the app, I should be directed to the tutorial page, which provides a brief summary of how to grow pineapples.
2. Given it's my first time logging in after signing up, after completing the tutorial, I should be prompted to input pineapple data to create a new pineapple plant.
3. Given it's my first time logging in after signing up, I should be required to choose among 5 different avatars for a cute and personal experience.
4. Given it's my first time logging in after signing up, on the "make plant page," I should be required to input plant name, plant height, and a picture of my plant to create my own pineapple plant.
5. Given I revisit the app, I shouldn't be shown the tutorial again and go right to Home page.
6. Given I am at home page, I should be able to see information about my pineapple and its picture and avatar.

3. Diary Entries

User Story:

As a user, I want to have the ability to create, read, update, and delete diary entries with various features for enhanced functionality and privacy control.

Acceptance Criteria:

1. Given I am using the app, I should be able to create new diary entries.
2. Given I am reviewing my diary entries, I should have the ability to update and edit existing entries.
3. Given I am reviewing my diary entries, I should be able to delete entries I no longer wish to keep.
4. Given I am creating a new diary entry, I should be prompted to fill in all required fields, ensuring that no fields are left empty.
5. Given I am creating a new diary entry, I should have the option to attach photos to my entry, providing a visual element to my diary.
6. Given I am creating a new diary entry, I should have the ability to choose a category that represents the topic or theme of my diary.
7. Given I am creating a new diary entry, I should be able to select whether the diary entry is private or public. Private entries should not be visible to friends or other users unless specified otherwise.

4. Accessing the Pineapple Disease Prediction Model

User Story:

As a user, I want a prediction model to understand and counteract the fruitlet core rot (fcr) diseases affecting my pineapple.

Acceptance Criteria:

1. Given I'm about to use the prediction model, when I haven't entered all necessary data, then the missing information is fetched from the current weather data by default.
2. Given I receive a disease likelihood result, when the risk is above a certain threshold, then I am provided with tips on treating or preventing that disease.

 

5. Following and Interacting with Friends

User Story:

As a user, I want to connect with friends, see their pineapples, and engage with their diaries to share our pineapple cultivation experiences.

Acceptance Criteria:

1. Given I am in the Friends Page and I searched a friend, when I click follow, then I can see friends pineapple details.

Unit Testing & Integration Testing

Overview

Unit Testing
In the development of our application, a rigorous approach was adopted for unit testing, particularly focusing on the data models integral to our API. This includes classes such as Diary.java and Friends.java. These unit tests are designed to validate the integrity and functionality of the data models, ensuring that they perform as expected in isolation. This step is crucial for verifying the correctness of individual components within the application.

Integration Testing
Integration testing was conducted with specific emphasis on critical components of the user interface, namely AuthoLoginActivity.java and AuthSignupActivity.java. These tests are structured to ensure that these components interact seamlessly with each other and with the underlying system. By simulating real-world scenarios, the integration tests validate the cohesiveness and reliability of the application's user authentication flow.

Backend Testing
For the backend, which is built on the Django framework, testing was primarily conducted manually using the Postman tool. This approach allowed for a thorough examination of the API's responses and error handling mechanisms. Through this process, we ensured that the API behaved as expected under various conditions, confirming the robustness and stability of the backend infrastructure.

Framework to be Used:

Unit Testing:

• JUnit for individual unit testing

Integration Testing:

• Espresso for UI testing

Strategies:

Unit Testing: Done by Pair Programmers

• Test the smallest parts of the application in isolation (e.g., functions, classes)

Integration Testing: Done by Project Manager

• Ensure that the different modules/parts of the application work together