-
Notifications
You must be signed in to change notification settings - Fork 1
Design and Planning
Rev. 1.0 2019-10-19 - initial version
장민석, 조민정, 김동현, 고지형
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.
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.
- Log in page(‘/login’)
- log in
- user input: email, password
- Sign up page(‘/signup’)
- create a new account
- user input: email, username, password, password_confirmation
- Main page(‘/main’)
- type search keyword on bar
- user input: keyword
- Search result page(‘/survey?key=word’)
- 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
- Survey detail page(‘/survey/:id’)
- show detailed information about the selected survey
- info: items(with brief response), pie-chart, abstract
- user clicks specific item, then show item response detail
- Cart page(‘/cart/:user’)
- ML : ‘/cart/:user/ml’
- show survey list added
- user can download survey results selected
- user can get similarity about selected surveys
- user can delete survey from cart
- Upload page(‘/survey/upload’)
- upload csv file about survey results
- can select items what user wants to share
- post a warning message about personal information
This is controller design. The controller executes the request(above the arrow) from the view part and passes the result to the model part.
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.
-
UploadPage: Page for uploading new survey results. First, UploadFile component is rendered. And if user uploads the .csv file, EditItem component is rendered right under. If the user checks all the items which does not include any personal information and pushes the submit button, Submit component is lastly rendered.
-
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.
-
CartPage: Page for user’s own cart. Buttons and surveys are rendered. There is subcomponent named CartSurvey. In CartSurvey, information of the survey is rendered and users can check the checkbox to analyze, delete or download. If the mlAnalysis button is clicked, server analyzes the result and react will render the results on the left part of the page.
-
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:
-
signInHandler: At Login page, sign in. Input: email- string, password- string
-
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.
-
deleteHandler: At Cart page, remove checked survey from cart. Deleted survey should disappear from screen.
-
mlAnalysisHandler: At Cart page, show analysis result about checked survey.
-
downloadHandler: At Cart page, download checked survey.
-
selectallHandler: At Cart page, select all surveys.
-
uploadHandler: At Upload page, it helps user to upload csv file.
-
editHandler: At Upload page, item checkbox is checked or unchecked.
-
submitHandler: At Upload page, Survey file is submitted and move to Main page only when user checks the admit box.
-
filterHandler: At SearchResult Page, it manages filter’s checkbox.
-
searchHandler: At SearchResult Page, show the searched result.
-
downloadHandler: At SurveyDetail Page, it downloads the csv file of the survey.
Subcomponents:
- ProfileButton: This dropdwon button, also subcomponent is in Pages except for Login and Sign up. It has two buttons- My Cart and Log out.
- MLResult: It shows the result of ml analysis- Title of the Item and number from analysis.
- ItemResponse: It is subcomonent of SurveyItem of SurveyDetail page. It is table that shows Item question and its responses.
- SurveyItem: It is subcomponent of SurveyDetail page. There is dropdown and ItemResponse subcomponent, which contains Item question and responses.
- UploadFile: It is one of subcomponents used in Upload page. It is shown initially after Upload page is loaded. Also it is module for uploading file.
- 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.
- Submit: It is one of subcomponents used in Upload page. There is text of warning for user who uploads survey and checkbox to admit the warning and submit 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.
- SearchSurvey: At SurveyResult page, search results are shown in turn through this subcomponent. In this component, there is SurveyBlock subcomponent and moveCart button.
- CartSurvey: At Cart page, cart items are shown through this subcomponent. In this component, there is SurveyBlock subcomponent and surveybox and checkbox.
- 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.
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.
- uploadHandler: At UploadFile subcomponent, if user clicks upload button, the file is uploaded and user goes to next step of uploading.
- submitHandler: At Submit subcomponent, if user clicks the submit button, informations and items of the survey are uploaded.
-
UserReducer: Used to handle and carrry current user’s basic information. This data will be used in authorizing page access.
-
SurveyReducer: It contains a single survey’s information. “item_list” consists of items which is described by pointer arrow. And response_list of an item consists of responses which is also pointed by arrow.
-
SurveyListReducer: It contains survey list. A single survey of the list looks same as SurveyReducer’s state.
-
CartReducer: It contains data about the current user’s cart. So it contains list of surveys and ml-analyzed results.
Frontend and Backend communicate through HTTP protocol, using the RESTful API. The total description about the API is provided below.
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).
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.
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.
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