Sprint2 Design and Planning Document
Design and Planning Document 11/13/2022
Above is the overall MVC pattern for our project. There are 7 Views and 5 Models. The controller is specified in the later part of this document.
Here is E-R(Entity Relationship) diagram for model design.
Rectangle stands for entity set, with attributes listed below. The top attribute with an underline represents the primary key for each entity. The relationships are linked with lines. For example, the user to Comment entity is mandatory to many optional relationships since users may or may not have written comments. This applies to the rest of the entities. models.py Product: added ‘rateCount’ that stores the total number of rates posted to a product. Rate: Added ‘averageScore’ that stores the average score of the newly posted rate. Added ‘created_at’ that stores the created time or the last edited time of the rate.
Difference: In View, we change Page Names written above. We combined several Detail Pages into one Detail Page. Header is changed according to user stories. Also Added Sign Up Page and after signing up, the user will be directed to Sign In Page.
Start with signin. If the user enters ID and Password and clicks the Sign In button. Go to Main Page with entered user ID.
Exists on all pages except for Sign In Page and Sign Up Page. If the user clicks MainPageButton, go to Main Page. If the user clicks CompanyButton, go to the Product List Page with a certain category. If the user enters searching keywords in searchingBox, then show the result that matches with a searched key in the Product List Page. If the user clicks my Page Button, show personal page information.
In the Main Page, we show randomly selected 4 products and up to 4 recommended products. If the user clicks a certain product block, show the detail product on the Product Detail Page.
The total page shows all the products in the CU site with sorting buttons. The sorting is provided with most popular products, highest rate, highest and lowest scores sorting filter.
shows product block list in grid style that matches filters of mainCategory. If the user clicks a certain product block, it shows a detailed product in the Product Detail Page. In each Category Page, all products are shown at once instead of showing them with a page index. There are sorting buttons with most popular products, highest rate, highest and lowest scores sorting filter.
shows product block list in grid style that matches certain filters like searching result products. If the user clicks a certain product block, it shows a detailed product in the Product Detail Page.
Product Detail Page performs four components. One is to see the detail of product(ProductBlock.tsx), another is the personal rate to the product(RatingForm.tsx), third is to show the total scores(TotalScoreList.tsx), and a list of all reviews by users on that product(ReviewList.tsx). The components that changes based on the state of user are RatingForm and the ReviewList. RatingForm which was originally in a single file is divided into 4 files, each with different states of before creating rate, creating rate, editing rate and after rating. Also, there is Rating Layout that calls each state of rate by checking whether user has rated a product. For Review List, 4 Buttons(togglePicture, likeButtonClick, recentButtonClick, pictureButtonclick) are newly made for sorting and toggling down. Also, useEffect is used 1. to set setRates the filteredRates that contains only the rates that are related to the product. 2. dispatch fecthUserLikedRate to get only the rates that a current user liked and show the heart in the right color(white/red) whenever the user enters the Product Detail Page.
If the user did not leave a rate If the user clicks clicks “내 평가 남기러 가기” button, user can leave review for the product. It shows “저장”button “취소”button. If the user clicks “저장” button, the review is saved. If the user clicks “취소”button, the user goes back to seeing “내 평가 남기러 가기” button. If user did leave a rate User can see “평가 수정” button and “평가 삭제” button. If user clicks “평가 수정” button, user can modify the review. User can click “수정 저장” button to save the edit or click “평가 취소”button to move back to seeing their review. If user clicks “평가 삭제”button, the review is deleted and user will see “내 평가 남기러가기” button again.
shows products that the user rated and comments that a user liked. If the user clicks a certain product block, it leads to its Product Detail Page. If the user clicks a certain review block, it leads to its Product Detail Page. Users are able to fix personal information. Also the comment blocks show user’s liked comments are shown with productBlock and liked comments one by one. The product block and comment lists are shown at once instead of page index. Also the user survey editing form is shown in modal.
Left side is the view part (frontend) and the right side is the model part (backend). Left-to-right arrow represents HTTP request with user inputs from the view, and right-to-left arrow represents HTTP response with data from the model. Above the arrow, there is an API that the controller uses to transfer JSON data below the arrow.
Frontend components are changed according to other changes.
Signup
- onclickSignupButton: Check the user input, if it is valid then redirects to sign in page and finish sign up process.
- onclickToSigninButton: Redirects to Signin Page.
- Signin
- onclickSignInButton: Check the user input, if it is valid then redirects to Main Page.
- onclickToSignupButton: Redirects to Signup Page.
Main
- onclickmoveRightButton: move all product blocks to right
- onclickmoveLeftButton: move all product blocks to left
- onclickNewestButton: show top 10 newest product blocks.
- onclickHottestButton: show the top 10 hottest product blocks.
Header Buttons
- onclickCompanyButton: Redirects to product List Page with certain category.
- onclickMyPageButton: Redirects to My Page.
- onclickHomeButton: Redirects to Main Page
- onclickSignOutButton: Sign out signed in user, redirects to login page.
Search
- onclickSearchButton: show product block lists that match with the searching key.
Search Result Page
- onclickNewestButton: show product block lists that match with the searching key in the newest order.
- onclickHottestButton: show product block lists that match with the searching key in hottest order.
- onclickPageButton : show another lists of product blocks matched the condition.
Product Block
- onclickProductBlock: Redirects to Product Detail Page.
Category Page
- onclickNewestButton: show product block with certain category in newest order.
- onclickHottestButton: show product block with certain category in hottest order.
- onclickCategoryButton: the ProductList page shows 12 products on one page. Below 12 products, there are page indexes to switch to another 12 products.
Product Detail Page
-
내 평가 남기러 가기
-
저장
-
작성 취소
-
수정
-
삭제
-
수정 취소
-
수정 저장
-
onclickRateHandler: show rating form for user to rate the product
-
onclickBackToRateHandler: return back to tab before clicking clickRateHandler
-
onclickSaveHandler: saves rate information
-
onclickDeleteHandler: deletes user’s rate
-
onclickEditHandler: allows users to edit the rate
-
onclickBackEditHandler: move back to tab before clicking clickEditHandler
-
onclickSaveEditHandler: saves the edited information
My Page
- onClickProductBlock: Redirects to Detail Page.
- onClickComment: Redirects to Detail Page that the comment was written on.
- onClickPageButton: Show up to 5 comments. Gets data from Comment using userID.
| Model | API | GET | POST | PUT | DELETE |
|---|---|---|---|---|---|
| User | /signup/ | X | Create new user | X | X |
| /signin/ | X | Sign in | X | X | |
| /signout/ | Sign out Logged in User | X | X | X | |
| /token/ | Get token | X | X | X | |
| /requestUser/ | Get information of request.user | X | X | X | |
| /userlist/ | Get all users’ information as list | X | X | X | |
| /newSurvey/int:user_id/ | X | X | Put a user's changed survey result | X | |
| Rate | /rate/ | get all rates(reviews) | Post user’s rate | X | X |
| /rate/user/ | Get a list of rates that a specific user posted | X | X | X | |
| /rate/liked/ | Get a list of rates that a specific user liked | X | X | X | |
| /rate/:rate_id/ | Get a specific rate | X | Edit a specific rate | Delete a specific rate | |
| Product | /product/ | Get product list | X | X | X |
| /product/:product_id/ | Get a product’s information by a product_id | X | Edit a product’s averageScore | X | |
| /product/:mainCategory/ | Get a list of specific maincategory’s products | X | X | X |
Our implementation plan gives the division of work into sprints and people. In each sprint, development covers almost all of the pages. Thus after each sprint, we will make the website to function at least the most fundamental functions. In the later sprint, we gradually cover up pages in the website and especially put more effort on Pages written below certain Sprint.
Until Sprint2, We developed the “Main” and “Sign In”, “Sign Up” page and basic “Product Detail” Page and “Header” component in sprint2 which creates the user and signs the user in and does basic frontend rating in Product Detail Page. We attreive products data in CU convenient store Online Official Page and save the Product model data in Django DB. Along with the product Model, we constructed User Model and successfully saved new user information in Django DB.
In Sprint 3, We will connect these pages and model classes with backend to save the user and product data. And we will Rating and Comment using the Product Detail Page. We will make a Category page to display products in certain categories from DjangoDB.
Including Sprint3, in later Sprints, we will do testing along with development and make sure that even though the function and design is simple but performed correctly and efficiently by using both travis CI and SonarCloud.
Furthermore, in order to store information related to rates users by users, we plan to create a 'like' class with rate and user as foreign keys. Based on this, we will display the status of the like in each review correctly for each user.
The division is according to the difficulties of tasks and the estimates of the time for tasks. First, the difficulties of tasks are expressed as numbers between 1 to 5. Second, the estimates of the time for tasks are in hours.
| Sprint | Page | Feature | Difficulties | Time (Hour) | Person | Challenges |
|---|---|---|---|---|---|---|
| 2 | Main | Product Block | 2 | 5 | MinJi Kim | |
| 3 | Main | Sliding View | 3 | 5 | MinJi Kim | Sliding View API |
| 2 | Main | Header | 2 | 8 | Jahyun Yun | Searching Algorithm |
| 2 | Sign In | Sign In | 5 | 10 | MinJi Kim | |
| 3 | Category Page | Grid View | 2 | 3 | Jahyun Yun | |
| 3 | Category Page | page change | 2 | 3 | Jahyun Yun | |
| 4 | Rate | ratingForm by categoryreview List | 5 | 15 | Hana OhNayeong Min | |
| 4 | Rate | edit, delete, rating | 3 | 10 | Hana OhNayeong Min | user sliding button |
| 4 | My Page | user Recordings | 2 | 5 | MinJi Kim |
Challenges in sprint2 are expected when implementing the searching algorithm in the header part. Also, the original signin plan that uses KakaoAPI has been modified to an ordinary ID-Password system. Further challenges are expected when using API for views.
In reality, challenges in sprint2 exist when combining backend and frontend modules. Also after getting into development, there are modifications in Designing Components and classes.
Challenges in sprint3 are expected when using the same model in several pages. We divided the function of pages to be performed in different models. One change in Frontend will affect other classes at the same time. As a result, handling the model data might be challenging. Moreover, we will add up and cover up implemented codes.
Testing plan and Testing will be implemented until Wednesday, 15th Nov. Below parts will be fixed later.
- Unit Testing We plan to test every component and module when they are implemented. The expected coverage is over 90%. The following are the modules we would like to use for the test.
- React: Jest & enzyme
- Django: Python unit test
- Functional Testing The APIs would be tested using mock data. We expect to test authentication and functionality on the main page by sprint 3. Then, we would proceed on to comment and rating API by sprint 4.
- React: Jest & enzyme
- Django: Python unit test
- Acceptance & Integration Testing We would use Cucumber testing to understand how the application should behave. We would specifically use Cucumber for acceptance testing. Using the user stories written in Sprint 1, we would utilize them in sprint 5. The following are the tool used for each test.
- Acceptance Testing: Cucumber
- Integration Testing: Travis CI