團隊基本情況

組長部落格連結

團隊專案的整體計劃安排

團隊分工和個人貢獻比

思維導圖和燃盡圖

• 思維導圖
  
• 燃盡圖
  

小練習

後端系統框圖

• 負責人：王祺

• 描述：我們使用的是分層分工法

• 該部分面臨的問題：按模組功能分工需要每個成員瞭解各個層次的業務邏輯，學習成本偏高

• 解決的問題：我們直接使用分層法，持久層的就專門與資料庫互動做CRUD，服務層專門搞業務邏輯，控制層專門做轉發、重定向、過濾等，與前端介面互動

實體層類圖

• 負責人：王祺

• 描述：實體類的設計與實體間的關係

• 該部分面臨的問題：怎麼對現實世界做出抽象並且與庫表建立聯絡

• 解決的問題：反向設計，由庫表推實體類，結合ORM的特性來設計實體類

【吃點兒啥】整體系統用例圖1（使用者為授權使用者）

• 負責人：王祺

• 描述：授權使用者對【吃點兒啥】小程式的大致使用

• 該部分面臨的問題：授權使用者如何使用該系統

• 解決的問題：讓授權使用者清晰get到對該系統的使用

  ​

【吃點兒啥】整體系統用例圖2（使用者為運維同學）

• 負責人：王祺

• 描述：運維對【吃點兒啥】小程式進行維護

• 該部分面臨的問題：運維同學如何使用該系統以及系統異常情況的處理

• 解決的問題：由運維同學負責檢視後臺日誌資訊，更改配置檔案等等方式達到維護目的
  

評價控制的活動圖

• 負責人：王祺

• 描述：每個人每天的評論數量是有限制的

• 該部分面臨的問題：防止單個使用者短時間內多次刷評論

• 解決的問題：記錄使用者當天的評論數量，超額則不予評價通過
  

​

視窗保護機制觸發的活動圖

• 負責人：王祺

• 描述：【視窗保護】的觸發

• 該部分面臨的問題：該如何防止大批惡意使用者刷評論

• 解決的問題：我們引入【視窗保護】的概念，當觸發異常條件，便執行該模組
  

視窗保護機制的活動圖

• 負責人：王祺

• 描述：【視窗保護】主要是針對惡意使用者的

• 該部分面臨的問題：大批惡意使用者刷評論

• 解決的問題：開啟【視窗保護】機制，當系統檢測到某視窗的評論在短期內大量增加，將該視窗判定為異常視窗，開啟保護，再次收到相同評價，直接返回評價失敗
  

​

菜品星級評算的活動流程圖

• 負責人：王祺

• 描述：使用者對菜品做出星級評價，達到一定星級加入我的愛心

• 該部分面臨的問題：菜品星級如何評算，怎樣才算是把菜品加入【我的愛心】

• 解決的問題：把每條評價查出來，重新加權計算星級並作顯示

  ![](https://img2020.cnblogs.com/blog/1842191/202011/1842191-20201101174045269-1341937477.png)
  

  ​

雲圖標籤推薦的活動圖

• 負責人：鄒薇

• 描述：使用者根據雲圖標籤獲得菜品推薦

• 該部分面臨的問題：部分菜品與推薦的標籤不符合

• 解決的問題：應用了使用者反饋機制，後臺通過使用者反饋資訊修改菜品標籤解決標籤與菜品不符問題

  ![](https://img2020.cnblogs.com/blog/1842191/202011/1842191-20201101174125931-1962873266.png)
  

我的頁面活動圖

• 負責人：鄒薇

• 描述：使用者在我的頁面可以實現的操作，進行使用者反饋，檢視愛心和收藏

• 該部分面臨的問題：使用者怎麼知道自己是否反饋成功

• 解決的問題：回覆使用者該反饋是否採納

使用者頁面的活動圖

• 負責人：鄒薇

• 描述：使用者根據自己喜好選擇標籤設定偏好和忌口

• 該部分面臨的問題：標籤不夠全面，使用者不知道從哪裡進入到該頁面

• 解決的問題：應用了使用者反饋機制，通過使用者反饋的資訊適當增加標籤，進行提示
  

就餐前的狀態圖

• 負責人：鄒薇

• 描述：就餐前使用者登入小程式獲得心儀的菜推薦

• 該部分面臨的問題：使用者不知道去哪裡吃，吃什麼，好不好吃

• 解決的問題：多種推薦機制，有熱門視窗直接推薦和可以進入雲圖更據選擇菜品標籤進行推薦。可以通過檢視菜品詳情來獲得菜品的星級
  

就餐後的狀態圖

• 負責人：鄒薇

• 描述：就餐後用戶登入小程式對菜品進行評星和反饋

• 該部分面臨的問題：無法判斷使用者是否為惡意評星和反饋

• 解決的問題：利用視窗保護機制對對使用者反饋覺評星進行評價其可靠性
  

持久層類圖

• 負責人：傅興佳

• 描述：展現實體類間的關係，以及提供了與資料庫互動的介面

• 該部分面臨的問題：需要與資料庫互動的功能較多

• 解決的問題：清晰的描述了用於增刪改查的介面
  

ER圖

• 負責人：傅興佳

• 描述：展現實體之間的關係，以及實體的屬性

• 該部分面臨的問題：實體較多，關係難以理清

• 解決的問題：理清了實體間的關係
  

【吃點兒啥】頁面跳轉流程圖

● 負責人：林逸麗

● 描述：在授權後進入首頁，選擇搜尋或者篩選雲圖，還有我的主頁。在搜尋和篩選後會出現視窗或者菜品，其中點選視窗會出現地圖指引。我的主頁中包含愛心視窗、收藏視窗、使用者介面。

● 該部分面臨的問題：

● 解決的問題：

【吃點兒啥】反饋用例圖

● 負責人：沈帥

● 描述：使用者可以在反饋頁面反饋資訊，運維人員在檢查完反饋資訊後決定成功和丟棄

● 該部分面臨的問題：使用者不知道反饋流程

● 解決的問題：清晰的描繪了反饋流程

【吃點兒啥】使用者資訊用例圖

● 負責人：沈帥

● 描述：在授權後進入使用者介面，可以修改個人資訊，如頭像，暱稱，口味等

● 該部分面臨的問題：使用者修改頭像想用自定義圖片

● 解決的問題：使用者頭像為微信頭像，可以修改微信頭像改變頭像。

前端登陸部分

• 負責人:蘇煒傑
• 描述:前端登陸部分包括,請求使用者授權,使用微信小程式 api 獲取登陸 code傳給後端,最終獲取userId 完成登陸.使用者退出登陸後返回未登入狀態,定時檢查登入資訊,諾失效需要重新登陸.
• 該部分面臨的問題:登陸狀態的時序問題
• 解決的問題:

使用 async await promise 用同步的方式編寫非同步程式碼,整理登陸狀態

• 附:
  

服務層類圖

• 負責人：傅興佳

• 描述：展現服務層的介面

• 該部分的問題：服務層介面在類之間的分配

• 解決的問題：清楚的分配了每個類應實現的功能
  

控制層類圖

• 負責人：傅興佳

• 描述：展現所有頁面可以跳轉的頁面

• 該部分面臨的問題：頁面跳轉邏輯混亂

• 解決的問題：清晰的描述了頁面的跳轉邏輯
  

作業記錄相關

UML設計工具的選擇、選擇的理由和使用後對工具的評價

• 選擇draw.io 選擇的原因是可以儲存到github，或者提取github的draw.io 檔案，方便共享。大家覺得很方便，可以免費線上使用，方便匯入。

遇到的困難及解決方法

• uml不會畫，通過網上學習和詢問隊友才掌握
• 拍攝原型視訊時各有想法，最後經過組長開會總結，確定視訊

學習進度條