Skip to content

Design

Jump to bottom
Junhyung Oh edited this page Dec 10, 2023 · 58 revisions

Document Revision History

Version Date Message
1.0 2023-10-08 initial
1.1 2023-10-18 edit class diagram and data models
1.2 2023-10-20 edit API
1.3 2023-11-05 edit system design and testing plan
1.4 2023-11-12 update user stories and user acceptance criteria
1.5 2023-11-15 update backend class diagram and DB schema
1.6 2023-11-19 update frontend class diagram
1.7 2023-12-03 update class diagrams, DB schema
1.8 2023-12-10 update class diagrams, DB schema, testing details

System Design

Tech Stack

tech_stack

System Architecture

system_architecture

Class Diagrams and Data Models

Frontend Class Diagram
FE class diagram

Backend Class Diagram
image

Database Schema
image

Implementation Details

API Specifications

SpeechBuddy uses RESTful API for communication between the client and the server. Implementation details can be found in a dedicated wiki page for RESTful API design.

Testing Plan

Unit Test

We aim to maintain a test coverage of at least 75% for both frontend and backend parts of our project, testing functions of major components of the project.
For example, in SettingsRepositoryTest, we test whether dark mode is saved when setDarkMode is called with true.
The framework to be used are:

  • Frontend (Android)
    • JUnit4
    • MockK (Mocking library for Kotlin)
  • Backend (Django)
    • Django Unit Test Framework

Integration Test

We plan to employ UI testing to our project as a type of integration test. Integration tests include UI test, covering correct behavior of application that can be tested on each screens.
For example, in LoginScreenTest, we test whether wrong email error message is displayed when invalid email given.
We used the ComposeTestRule, a set of APIs provided by compose, to test the various interactions and behaviors of our app's UI layer.

Coverage

The displayed coverage is lower than the actual number because androidTests(including integration tests) are not included in the coverage.

Example coverage for remote data components image

Component Class Coverage Method Coverage Line Coverage
local data models 100% 93% 94%
remote data models 84% 57% 61%
remote data requests 87% 87% 88%
domain models 100% 100% 100%
domain utils 100% 100% 100%
repository 52% 66% 67%
service 100% 100% 100%
ui models 90% 90% 94%
utils 80% 84% 70%
viewmodel 59% 67% 66%

User Acceptance Test

We plan to proceed the User Acceptance Test (UAT) with the five user stories and user acceptance criteria below.

  1. Related Features : Symbol selection, Next word prediction
    As a user who relies on symbol selection for communication and faces challenges in promptly finding the next symbol, I can benefit from next-symbol recommendation algorithm based on my usage history, so that I can enjoy a faster and more efficient communication.
    Scenario : Users should experience personalized next-symbol recommendations(predictions) to enhance communication efficiency
    Given that a user has frequently selected "가져와주세요" after choosing "가방" to express "가방 가져와주세요"
    When he/she selects "가방" to convey "가방 가져와주세요" again
    Then he/she should observe "가져와주세요" positioned on top of the symbol list, followed by subsequent symbols that are arranged based on the recommendation algorithm.

  2. Related Features : Symbol selection, Search
    As a user who wants to look for a specific symbol to choose subsequently, I can search for a particular symbol or category in mind by typing, so that I can find the optimum symbol for me.
    Scenario : Users should be able to search and find a specific symbol to express their thoughts
    Given a situation where a user tries to find "더워요" symbol
    When the user types "더" to search for the "더워요" symbol
    Then he/she must be able to easily find the symbol in the search result.

  3. Related Features : Symbol selection, Add to favorites
    As a user who has frequently-used set of symbols, I can add those symbols to my favorites list, so that I can find them easily later.
    Scenario : Symbols that are frequently used should be more easily accessible
    Given a context where a user consistently utilizes a small set of symbols
    When the user touches the heart icon on the upper right of the symbol, the symbol is added to his/her favorite list
    Then the user should be able to conveniently find these preferred symbols by selecting the "show favorite symbols only" menu.

  4. Related Features : Text-to-speech
    As a user who is physically unable to produce sounds, I can write down my thoughts and make them to be read aloud using TTS feature, so that I can convey my ideas to others, using sound.
    Scenario : Those with speech impairment should be able to express themselves out loud
    Given that a person who has difficulty in uttering needs to attract other's attention to inform that he/she needs help
    When he/she writes “도와주세요” in TTS screen of our app
    Then the app should read aloud the phrase on behalf of him/her.

  5. Related Features : Symbol creation
    As a user who wants to express creative thoughts, I can add new symbols to the symbol list by uploading my own photos and have them converted into new symbols, so that I can freely express my own ideas using new symbols.
    Scenario : Users should have the ability to personalize symbol lists based on their preferences
    Given a context where the user tries to find a symbol in the list to express his/her thoughts but can’t find one
    When the user navigates to the ‘symbol creation’ screen, uploads his/her own photo from the gallery, provides name and category for the photo, and have them converted into a new symbol to be added into the symbol list,
    Then the new symbol should be displayed in the symbol list of ‘symbol selection’ screen.

Clone this wiki locally