| 這個作業屬于哪個課程 | 2020春-S班(福州大學) |
|---|---|
| 這個作業的要求在那裡 | 團隊作業第四次—項目系統設計與資料庫設計 |
| 團隊名稱 | Hail Hydra(九頭蛇) |
| 這個作業的目标 | 完成項目的系統設計和資料庫設計 |
| 作業正文 | |
| 其他參考文獻 | 百度，CSDN |
開發計劃時間表
| 工作安排 | 截止時間 | 完成情況 |
|---|---|---|
| 完成系統設計，學習所需技術架構，完成前後端互動測試 | 2020-4-7 | 完成 |
| 完成資料庫設計，确定接口傳輸資料格式，搭建項目基本架構 | 2020-4-13 | |
| 前端完成靜态頁面，後端完成對應接口的資料處理 | 2020-4-19 | 待完成 |
| 前後端進行對接，完成接口測試，處理錯誤，釋出Alpha版本 | 2020-4-26 | |
| 前端對界面細節進行優化，後端完成權限處理，增強系統健壯性 | 2020-5-3 | |
| 前後端進行功能測試，修複bug | 2020-5-10 | |
| 正式版本完善，将項目部署到雲伺服器，完成項目使用手冊，完善項目文檔 | 2020-5-17 | |
| 正式版本釋出，項目總結和彙報 | 2020-5-24 | 帶完成 |
團隊項目的預期開發計劃分工安排
前端
| 姓名 | 分工 |
|---|---|
| 袁錦輝 | 完成登入界面；普通使用者登入界面的靜态頁面；完成登入、首頁、等你來答，搜尋框，詳情界面的資料互動 |
| 黃子峻 | 完成個人中心我的問題、我的回複、我的消息、修改密碼的資料互動、完成前端普通使用者部分所需文檔 |
| 唐志豪 | 完成管理者界面靜态頁面,舉報資訊管理、使用者管理，積分管理，新增闆塊管理的資料互動 |
| 黃忠雄 | 完成個人資訊闆塊資料的互動，後期協同測試、完成前端背景頁面所需文檔 |
後端
| 翁紹鴻 | 完成功能子產品中的回複子產品、消息子產品、獎勵子產品 |
| 張嘉偉 | 完成問題子產品、投訴資訊管理子產品 |
| 劉成華 | 完成使用者賬号管理、臨時闆塊管理、權限管理 |
| 韋琛 | 負責測試，并跟進各個階段的文檔 |
項目體系設計
架構設計
采用原因
本系統采用MVC設計架構，目的是為了使得前後端可以完全分離，後端團隊在于前端團隊确定好接口和資料結構後二者可以并行開發，進而提高效率。同時采用MVC架構使得前端視圖和後端業務相分離，更容易改變程式的業務規則，提高了項目開發的靈活性和控制性。
資料流圖
各層次之間配合流程
（1）Controller層：擷取前端資料，并判斷應調用的Service對象/函數
（2）Service層：對Controller層傳入的參數進行處理，将資料轉換為Model層對象，并對資料庫進行增删查改操作，在處理結束後将前端所需的Model資料封裝成 View對象傳回給Controller層
（3）Controller層：将Service層傳回的對象加上狀态碼等資訊進一步進行封裝，并傳回給前端。
功能子產品層次圖
劃分依據與原因
本項目主要分成7個子產品（使用者賬号管理、問題管理、回複管理、臨時闆塊管理、投訴資訊管理、獎勵管理和消息管理）。劃分的主要依據是按照實際的功能劃分，子產品的功能盡可能的單一，操作對象也盡可能單一，其目的是為了使得各個子產品之間盡可能互相獨立，在開發分工中可以并行開發不同的子產品，避免因耦合度太高而帶來合作難度的提高。
設計類圖
Controller類與Service類依賴關系圖
第1、4行是系統的控制層，主要為前端提供資料接口，接受前端的資料請求，并經過判斷後調用相應的服務層對象對資料進行處理，最後對服務層傳回的資料結果進行包裝傳回前端。控制層的設計是根據功能子產品的劃分，即每個功能子產品都有自己對應的控制類，共包含9個控制類分别為：QuestionController、ResponseController、MessageController、AttentionController、BlockController、ReportController、LoginController、UserController、RewardController
第2、3行對應的是服務層對象，作用是為控制層的功能進行具體實作，負責對資料的處理，資料庫的更新，并将處理後的結果傳回包裝成對應的視圖層對象傳回給控制層。
QuestionService細節類圖
在QuestionService類的設計中我們采用了政策模式對類的清單擷取方式算法進行封裝，因為在系統的前台頁面中有多個界面都要擷取問題清單，但是排序方式卻不盡相同，若将這些算法全部都寫在QuestionService類内部則會導緻類十分的臃腫，增加了類的設計和實作難度，同時也給後期維護帶來了困難。是以我們采用政策模式對類中擷取清單方式的算法進行封裝，通過繼承公共類的方式使得互相之間可以替換，進而實作更換擷取算法卻不影響用戶端的效果。
ResponseService細節類圖
ResponseService類設計與QuestionService類似，是對擷取回複清單的方式進行封裝。
MessageService細節類圖
MessageService類也采取了政策模式，主要是因為針對不同的消息系統有不同的處理方式，不同的處理方式寫在不同的政策類中會提高系統的可擴充性。同時因為本系統有涉及積分的計算，很多的操作都會影響使用者的積分，如：寫問題，回複問題等，若将積分的處理分散在系統的各個地方則會給後期維護帶來困難，是以我将積分的處理也放在了政策類中。 設計帶來的好處：1.提高了類的可擴充性 (開閉原則)2.提高了程式的可維護性 (單一職責原則)3.使用聚合的方式設計政策類，有利于其他類對政策類的複用 (合成複用原則)4.使邏輯更加清晰，處理方法可以獨立變化不互相影響5.簡化了MessageService的設計和實作難度。
實體類圖
資料庫設計
資料庫表設計概述
在資料庫設計方面我們采用的關系型資料庫，共設計了10張表，每個實體類都有對應的資料庫存儲表。其中為了提高問題表的查詢和更新效率，我們将問題的标題和内容分别單獨提取出來設定一張表來存儲。
使用者表：存儲使用者的基本個人資訊
賬戶資訊表：存儲使用者的賬戶資訊，如經驗值，等級等
問題表：用于存儲問題的資料資訊，如回複數，投訴數等
回複表：用于存儲回複的資料資訊，如點贊數，點滅數等
标題表：用于将問題的标題單獨放到一張表中存儲
内容表：用于将問題和回複的内容單獨放到一張表裡存儲。
關注表：用于記錄使用者的關注問題
消息表：用于存儲使用者的消息記錄
獎勵申請表：用于記錄所有使用者的獎勵申請記錄
臨時闆塊表：用于儲存前台臨時闆塊的資訊
具體更為細節的設計說明請參考《資料庫設計說明書》
ER分析
使用者資訊局部ER圖
我們将賬戶資料（如積分，經驗值等）從使用者表中剝離出來，主要是為了使得表所對應的實體類能更清晰，不包含一些不必要的資訊（如管理者使用者不需要積分，經驗值等賬戶資料）；所對應的代碼設計是将賬戶資料作為一個類成員對象作為使用者類的屬性，當不需要該屬性時，該屬性可以為空。在表中二者展現為擁有關系。在資料庫中存放的消息與使用者之間的關聯主要是通過消息表中的被操作者id，使用者作為表中的操作對象，用于前台頁面的消息展示。
使用者對應資料庫表中的使用者表，在類圖中對應User類
賬戶資料對應資料庫表中的賬戶資訊表，在類圖中對應AccountData類
獎勵記錄局部ER圖
在表的設計中，使用者和獎勵記錄建的關系是申請關系，即使用者申請後建立的獎勵記錄，二者通過獎勵記錄中的使用者id外鍵關聯，一個使用者可以有多個獎勵記錄，是以二者之間是一對多的關系。
使用者對應資料表中的使用者表，在類圖中對應User類
獎勵記錄對應資料庫中的獎勵申請表，在類圖中對應Reward類
使用者-問題局部ER圖
使用者和問題之間主要有兩種方式關聯：
一是通過問題的作者id外鍵關聯，展現為建立關系，是使用者建立問題，因為一個使用者可以建立多個問題，是以二者間展現的是一對多的關系。
二是通過關注，使用者通過關注問題可以與問題産生關聯，這裡因為别人的問題和使用者之間沒有直接字段上的關聯，是以我們在中間加入了一個關注表，用于記錄使用者和問題之間的關注資訊，使用者和關注間展現1對多的關系（一個使用者可以關注多個問題），問題和關注之間也是一對多的關旭（一個問題可以被多個使用者關注）
問題對應資料庫表中的問題表，在類圖中對應Question類
使用者對應資料表中的使用者表，在類圖中的對應User類
關注對應資料表中的關注表，在類圖中對應Attention類
使用者-問題-回複局部ER圖
使用者和問題，回複之間主要是通過實體中的作者id作為外鍵關聯，展現的是建立關系，回複與問題之間通過回複表的問題編号産生多對一的關聯，展現一個問題可以有多個回複。
回複對用資料庫表中的回複表，在類圖中對應Response類
問題對用資料表中的問題表，在類圖中對應Question類
問題-回複局部ER圖
在問題和回複中都有一些資料較為龐大的字段——内容/标題，該部分字段不僅資料較大，而且很少更新（主要更新的是點贊數，評論數等資料），根據設計約定第四條，我們将标題和内容從表中抽離，單獨形成一張表，通過回複/問題的外鍵相關聯，提高表的查詢，更新效率。
内容對應資料表中的内容表，在類圖中對應Content類
标題對應資料表中的标題表，在類圖中對應Title類
回複對應資料表中的回複表，在類圖中對應Response類
問題對應資料表中的問題表，在類圖中對應Question類
總ER圖
系統安全和權限設計
系統安全性
針對系統的安全性，我們考慮了以下幾種常見的web攻擊方式，并制定了一下幾種應對政策
CSRF(跨站請求僞造)
CSRF是指在使用者登入後系統會将使用者資訊儲存到使用者浏覽器存儲，若使用者同時一些惡意的網站，這些網站可能會利用存儲的使用者資訊進入系統，進而可以對資料進行讀取和破壞
解決方案：在過濾器中進行referer識别，若referer為空或不屬于自身域及子域，則拒絕後續操作
SQL注入
SQL注入是指某些使用者在輸入某些資料的時候會故意加上一些SQL語句，若沒有經過處理直接拿這些資料進行資料庫操作可能會導緻跨越權限或對資料造成損壞。
解決方案：登入賬号在進行資料查詢前會進行字元檢查，賬号隻能由字母和數字組成。例：輸入為“123 or ‘1’ = ‘1’”的賬号将不會進行資料庫查詢，直接判為賬号錯誤
SSX(跨站腳本攻擊)
SSX是指某些使用者存入資料庫的資訊（如系統中的問題标題等）中夾雜js代碼，若使用jsp等方式直接将值嵌入html語句中有可能在頁面加載時執行該部分語句達到某些目的。
解決方案：前端内容指派全部通過js改變dom對象的innerHTML屬性可以避免該情況的發生
其他的資料安全性設計
在前後端資料傳輸的過程中對使用者的資料進行加密處理（具體的加密算法還沒有決定，等到項目進行安全性部分時再決定具體采用那種加密算法）
系統權限設計
本系統共有兩種使用者，三種角色每種角色對應的權限如下：
管理者(管理者使用者)：
登入進入的是背景頁面，能夠對所有使用者具有增删查改權限；同時也對文章和評論具有檢視、删除權限；對獎勵記錄具有檢視和删除權限；
老師(普通使用者)：
進入前台頁面，具有對問題、回複進行建立和查找權限；具有檢視和修改本使用者資訊的權限；相較于另一個普通使用者老師沒有兌換獎勵的權限
學生(普通使用者)：
進入前台頁面，對問題、回複具有建立和檢視權限，同時具有兌換獎勵權限；使用者操作隻具備檢視和修改本使用者的權限
針對老師助教和其他同學提出的建議進行的改進
類圖
在類圖方面，我們在上次作業中完成的不是很完整，我們這次在進行系統結構設計後，根據系統的結構設計和功能劃分對類圖進行了更為細緻的設計，使得每個功能和接口都有對應的類進行處理
傳輸資料的加密
在上次答辯中我們在安全性方面漏考慮的資料在傳輸過程的加密，在讨論後我們決定最後在安全性實作階段在資料傳輸前進行加密，以保證敏感資料不會被竊取。
完成這次工作的工作流程
- 初步學習了項目所需要的技術架構，進行了簡單的測試（包括前後端互動測試，資料庫增删查改測試）
- 根據測試讨論項目具體的實作方式
- 後端讨論并細化類圖設計，與前端人員确定接口并整理成資料文檔
- 前後端讨論并确定前後端借口具體傳輸的資料格式，并整理成文檔
- 根據系統設計搭建項目上傳
貢獻度表格
| 學号 | 貢獻度 | ||
|---|---|---|---|
| 021700613 | 參與管理者界面接口設計，并完成相應文檔 | 10 | |
| 221600313 | 參與普通使用者前台頁面的接口設計，并完成相應文檔 | ||
| 221701118 | 參與資料庫設計，系統架構設計，完成活動圖 | 12 | |
| 221701136 | 尋找并學習管理者界面所需要的前端技術，參與管理者頁面的接口設計 | 15 | |
| 221701219 | 完成系統設計說明書部分内容，完成資料庫設計說明書部分内容，完成資料庫設計ER圖 | ||
| 221701240（生病） | 鄭逸豪 | 生病住院 | |
| 221701316 | 參與資料庫設計，系統架構設計 | 11 | |
| 221701335 | 學習前台普通使用者界面所需要的前端知識，參與普通使用者界面接口設計 | 14 | |
| 221701421 | 參與接口設計，資料庫設計，系統架構設計，完成部分部分系統設計說明書，完成部分資料庫設計說明書，答辯+制作PPT，完成部落格 | 16 |
附件連結
Github 團隊倉庫連結
校園幫幫網_系統設計說明書
校園幫幫網_系統設計和資料庫設計答辯PPT
校園幫幫網_資料庫設計說明書
接口傳輸資料設計