Skip to content

Design and Planning

Jump to bottom
Kojihyung edited this page Dec 17, 2019 · 51 revisions

surBing(team11) - Design and Planning

Rev. 1.0 2019-10-19 - initial version
Rev. 2.0 2019-11-27 - edited version
Rev. 3.0 2019-12-17 - final version

Member

장민석, 조민정, 김동현, 고지형

System Architecture

Overview

image
The overall architecture is based on MVC(Model-View-Controller) pattern. React & Redux app has a role of View part. Django app has a role of Model part. View and Model communicates through the controller with HTTP protocol. Axios will handle the interaction between frontend and backend. Each components of the system are discussed in detail in the below sections.

E-R Diagram

image Here is the E-R diagram of the backend model in this service. For any one-to-many relationship, there are intermediate tables which maps primary key of one model to primary key of another model. In every model, the entities are listed by rows. For all models, the id entity is the primary key. The cart model has only the primary key, but is separated from the user since we may want to add some more attributes to the cart. Detailed explanations (with the backend core functions) are provided in later section.

View

image

  1. Log in page(‘/login’)
  • log in
  • user input: username, password
  1. Sign up page(‘/signup’)
  • create a new account
  • user input: email, username, password, password_confirmation, age, gender
  1. Main page(‘/main’)
  • type search keyword on bar
  • user clicks ‘Add New Survey’ button, then goes to make page
  • user clicks ‘Participate On Surveys’ button, then goes to participate page
  • user input: keyword
  1. Make page('/making')
  • user can make survey form
  • user input : title, content, open date, due date, target age, target gender, respondant number, items(title, type, options)
  1. Participate page(‘/participate’)
  • user clicks specific ongoing survey, then goes to responsing page about that survey
  • user can see ongoing survey list which can participate
  1. Responsing page(‘/responsing’)
  • user can response on survey.
  • user clicks ‘submit’ button, then goes to participate page
  1. Search result page(‘/search’)
  • show the searched survey results
  • user can re-search with other keywords
  • can use filter to filter search results by age
  • user clicks specific survey block, then goes to survey detail page
  • user can add surveys to cart for downloading or analyzing
  • user input: keyword
  1. Survey detail page(‘/survey/:id’)
  • show detailed information about the selected survey
  • info: items(with brief response), chart, abstract, related survey(2)
  • user clicks specific item, then show item response detail
  • user can download survey
  1. my page(‘/mypage’)
  • composed of my surveys, participated surveys, my cart
  • my surveys : user can see ongoing surveys and opened surveys
  • participated surveys : user can see participated surveys
  • my cart : user can see my cart list
  • if there’s no survey, user can see ‘go to OO’ button

Controller

image
This is controller design. The controller executes the request(above the arrow) from the view part and passes the result to the model part.

Design Details

Frontend

image underlined text : subcomponent

Components:

  • SignUpPage : Page for signing up to our service. Input boxes for username, email, password, password confirmation and submit button exists within the page. It can be linked to LoginPage.

  • LoginPage: Page for logging in to our service. Input boxes for email and password and submit button exists. It can be linked to SignupPage.

  • MainPage: Main page of our website. It has a search Bar, search button, and a button linked to the upload page.

  • MakingPage: Page for making survey form.

  • SearchResult: Page for showing searched results. Search Bar component and Filter component are needed. Search Bar is same component as used in Main Page. Each SearchSurvey components from search results show survey title and piechart through SurveyBlock component. Filter component is rendered to the left side and provides users the additional keyword searching and age filtering.

  • myPage: Page for user’s own informations and surveys.

  • SurveyDetail: Page for showing survey response. There are subcomponent named SurveyItem that includes information about survey item’s title and response, and subcomponent named surveyRelated that shows related survey.

Functions:

  • LoginHandler: ( LoginPage ) Do log in tasks.

  • signUpHandler: ( SignUpPage ) Create new user. After sign up completed, it automatically moves to Login page.

  • isLoggedin: At Main, Cart, Upload, SearchResult, SurveyDetail page, check if the user is logged in. If it is not, it automatically moves to Login page.

  • addSurveyHandler: At Main page, the page moves to Upload Page.

  • downloadHandler: At Cart page, download checked survey.

  • submitHandler: At Making page, Survey form is submitted and move to Main page.

  • filterHandler: At SearchResult Page, it manages filter’s checkbox.

  • getCart: At Mypage, it gives user’s cart list.

  • getSurveyOngoing: At Mypage, it gives user’s ongoing survey list.

  • getUserInfo: At Mypage, it gives username and point.

  • getParticipated: At Mypage, it gives user’s participated survey list.

  • getSurveyAll: At Mypage, it gives user’s completed survey list.

  • downloadHandler: At SurveyDetail Page, it downloads the csv file of the survey.

Subcomponents:

  • CartSurvey: At Cart page, cart items are shown through this subcomponent. In this component, there is SurveyBlock subcomponent and surveybox and checkbox.
  • SearchSurvey: At SurveyResult page, search results are shown in turn through this subcomponent. In this component, there is SurveyBlock subcomponent and moveCart button.
  • SurveyBlock: It is widely used subcomponent which is in SearchSurvey and CartSurvey subcomponent. There is title and chart expression of the survey and button that moves to SurveyDetail page if user clicks.
  • Edititem: It is one of subcomponents used in Upload page. It is shown after user clicks the upload button. There is itemCheckBox which user can select by clicking whether to upload correspond item or not.
  • TableForm: It is used for mypage.
  • SurveyItem: It is subcomponent of SurveyDetail page. There is dropdown and ItemResponse subcomponent, which contains Item question and responses
  • ItemResponse: It is subcomonent of SurveyItem of SurveyDetail page. It is table that shows Item question and its responses
  • ML: It shows the result of ml analysis- Title of the Item and number from analysis
  • ProfileButton: This dropdwon button, also subcomponent is in Pages except for Login and Sign up. It has two buttons- My Cart and Log out
  • TopBar: This is a bar which always allows users to move to other pages.
  • Graph: It shows the detail results of survey by chart. It converts the data for chart and shows it by piec-hart and block-chart.
  • SearchBar: It is subcomponent used in searching. There is space for input keyword and search button to get search result.
  • Filter: It is used in SearchResult page. There is button to get filtered result and checkbox for filter respondents’ age, and space for input other keyword.
  • ResponsingOption: It is used in ResponsePage.
  • ResponsingItem: It is used in ResponsePage.

Subcomponents- Functions:

  • moveCartHandler: At SearchSurvey subcomponent, if user clicks the moveCart button, relevent survey is added to user’s cart list.
  • surveyDetailHandler: At SurveyBlock subcomponent, if user clicks the toSurveyDetail button, the page automatically moves to the SurveyDetail page.
  • submitHandler: At EditItem subcomponent, if user clicks the submit button, it goes to next step of uploading.
  • mycartHandler: At ProfileButton subcomponent,the page moves to user’s cart.
  • logoutHandler: At ProfileButton subcomponent, user log out.
  • searchHandler: At SearchBar subcomponent, if user clicks search button, it redirects to SearchResult page and searched result is shown.
  • clickListener: At Filter subcomponent, if user clicks filter button, filtered results are uploaded in page.
  • radioHandler: At ResponsingOption subcomponent.
  • write_back_response: At Re ResponsingItem subcomponent.

API

Frontend and Backend communicate through HTTP protocol, using the RESTful API. The total description about the API is provided below. image

Backend

image As we mentioned above, every model has an id entity as its primary key.

user : model for each user

  • email [string, len <= 40] : The email address for the user
  • username [string, len <= 20] : The username for the user
  • password [string, len = constant] : The hashed password for the user
  • cart_id [int] : Foreign key which maps to corresponding cart for the user

survey : model for each uploaded survey

  • author_id [int] : Foreign key which maps to the author of the survey [int]
  • date [date object] : The date when the survey was published
  • title [string, len <= 50] : The title of the survey
  • content [string, length unlimited] : The explanation for the survey
  • response_count : The total number of people who responded to the survey

item : model for each item contained in the survey

  • title : The title of the survey
  • most_three_response[3] [array of [string, length unlimited], len = 3] : (Up to) Three responses which have the
  • most number of people who has that response. Sorted by response number, many to few.
  • most_three_count[3] [array of int, len = 3] : Response number for each most_three_response[] element.
  • response_count : The total number of people who responded to the item (may be different from the survey’s response_count)

response : Model for each response in the item

  • response_id [int] : A unique id which binds to the each responders in the survey. It is needed to group the
  • responses from the same responders, while anonymizing the responders.
  • content [string, length unlimited] : The response content.

cart : Model for cart for each user

  • Currently, this model has no entities rather than the primary key.

cartEntry : Model for each cart entry

  • survey_id [int] : The foreign key which maps to the corresponding survey.

Intermediate table : As mentioned above, intermediate table maps one model’s primary key to another model’s primary key. We need four intermediate tables as follows.

  • user_survey
  • survey_item
  • cart_cartEntry
  • item_response

Functions We divided the backend functions into three categories : user, survey, cart. User functions

  • add_new_user : Handles signing in new user.
  • log_in : Handles user log in.
  • log_out : Handles user log out.

Survey functions

  • add_new_survey : Add new survey datas to the database when a new survey is published.
  • search_survey : Search surveys by keyword.
  • get_survey : Get survey by id (primary key).
  • delete_survey : Delete survey by id.
  • get_items : Get survey items for given survey id.
  • get_responses : Get survey responses for given item id.

Cart functions

  • get_surveys_on_cart : Get surveys on the cart.
  • add_to_cart : Add survey to cart.
  • delete_from_cart : Delete survey from cart.
  • get_relevant_analysis : Get ML analysis results of relevant survey items. this function is discussed in more details in below section (ML Feature).

ML Feature

We have used Twinwords text similarity API to calculate the similarity of two surveys. When we send the two survey's title packed as json to the api, it returns the similarity as a number between 0 and 1. We can now traverse the survey database, and store the top 2 surveys which is most similar for every surveys on the opened db. This method will reduce the amount of space required than storing all similarities among them.

Implementation Plan

image In sprint 3, we will have some more discussions about the design, since the plan will surely change as we start the actual implementation. Also, we have to make all parts of the frontend work (at least with mock backend data) to prepare the project progress presentation. Main coding works are placed in sprint 4. after this sprint, the user should be able to use all of the core features of the service. For sprint 3 and 4, we have to be implicitly preparing for the ML feature. We’re planning to do the actual implementation mainly in sprint 5. After sprint 5, we should get the complete service, supporting all the specs listed in the Specification document.

Work devision

image

Testing Plan

Test every components and modules -> Test that rendering is done as intended -> Test when changing reducer or actions, update is done as intended -> Test that components interact correctly -> Final test from the user’s point of view

  • Unit testing Test every components and modules. For each sprint, test the components implemented. Coverage is at least 85%. Framework: React & Redux : jest, enzyme Django : Python test

  • E2E testing(functional testing) Test the whole system is working properly. From the user’s point of view, checking what is directly exposed to the user. In final sprint, we will do this. Framework React : Cypress Django : Python test

  • Integration testing When an event is fired, test that desired change occurs in the UI. All required properties of a particular component are properly passed to the descendant component. In sprint 4, we will do this. Framework React & Redux : jest, enzyme Django : Python test

Clone this wiki locally