| 這個作業屬於哪個課程 | 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類
用戶對應數據表中的用戶表，在類圖中對應User類
問題-回復局部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 | 黃子峻 | 參與普通用戶前台頁面的接口設計，並完成相應文檔 | 10 |
| 221701118 | 張嘉偉 | 參與數據庫設計，系統架構設計，完成活動圖 | 12 |
| 221701136 | 唐志豪 | 尋找並學習管理員界面所需要的前端技術，參與管理員頁面的接口設計 | 15 |
| 221701219 | 韋琛 | 完成系統設計說明書部分內容，完成數據庫設計說明書部分內容，完成數據庫設計ER圖 | 12 |
| 221701240（生病） | 鄭逸豪 | 生病住院 | 0 |
| 221701316 | 劉成華 | 參與數據庫設計，系統架構設計 | 11 |
| 221701335 | 袁錦輝 | 學習前台普通用戶界面所需要的前端知識，參與普通用戶界面接口設計 | 14 |
| 221701421 | 翁紹鴻 | 參與接口設計，數據庫設計，系統架構設計，完成部分部分系統設計說明書，完成部分數據庫設計說明書，答辯+制作PPT，完成博客 | 16 |