| 這個作業屬於哪個課程 | <班級的鏈接> |
|---|---|
| 這個作業要求在哪里 | <作業要求的鏈接> |
| 這個作業的目標 | 1.項目系統設計 2.數據庫設計 3.《系統設計說明書》 4.《數據庫設計說明書》 5. 答辯ppt |
| 其他參考文獻 | 1.阿里巴巴Mysql數據庫規約 2.數據庫設計說明書編寫規范(國標) 3.數據庫系統概論(第四版) 王珊，薩師煊編著 高等教育出版社 4.構建之法(第三版) 鄒欣編著 人民郵電出版社 |
預計開發計划
時間安排
| 周 數 | 任務目標 | 具體日期 |
|---|---|---|
| 第8周 | 全體成員：完成系統設計和數據庫設計任務（4.23止） 后續（增加知識儲備）： 前端成員：跟進學習微信小程序開發知識，vue框架知識 后端成員：繼續跟進SpringBoot框架的學習 |
4.19~4.25 |
| 第9周 | 繼續學習開發框架，學習敏感詞驗證，審核策略等算法。 根據之前的分工，前后端開始進行開發 前端成員：1. 成員間做好任務分配 2. 完成部分微信小程序界面的開發，並做好簡單交互功能 3. Web端后台界面同步開發 后端成員：1. 成員間做好任務分配 2. 對之前設置的接口,數據庫進行編寫 3. 與前端多加交流，調整任務 |
4.26~5.2 |
| 第10周 | 1. 繼續完善上一周的任務 2. 對其他前面未完成的功能進行編寫 3. 進行前后端整合及測試，修復遇到的bug 4.發布alpha版本 |
5.3~5.9 |
| 第11周 | 1. 完善功能 ，修復存在的bug 2. 反思alpha版本開發存在的問題 3. 討論程序設計的問題或者缺陷，對程序進行必要的重新設計 |
5.10~5.16 |
| 第12周 | 1. 對上一次程序版本進行反思，尋求解決方案 2. 繼續加強對開發相關知識的學習 |
5.17~5.23 |
| 第13周 | 繼續加強對開發相關知識的學習 | 5.24~5.30 |
| 第14周 | 根據之前的反思結果方案進行再開發 | 5.31~6.6 |
| 第15周 | 編寫和完善代碼，對程序進行測試 | 6.7~6.13 |
| 第16周 | 1. 編寫和完善代碼，對程序進行測試 2. 發布beta版本 3. 事后總結 |
6.14-6.20 |
人員分工
| 學號 | 職位 | 工作內容 |
|---|---|---|
| 221801125 | PM | 項目進度安排，項目進度監督，項目文檔更進 |
| 221801104 | 美工 | 界面UI，界面美化 |
| 221801209 | 后端 | 權限設置，數據庫操作 |
| 221801215 | 后端 | 帖文頁面接口 |
| 221801222 | 前端 | 前后端對接 |
| 221801230 | 前端 | 貼文卡片，組局卡片，消息卡片 |
| 221801231 | 前端 | 界面框架，界面拼接 |
| 221801321 | 后端 | 組局頁面接口 |
| 221801411 | 后端 | 個人中心接口，微信認證 |
系統結構設計
結構設計
整個軟件共分為7個模塊，分別是
-
認證模塊
-
校友圈模塊
-
消息模塊
-
發帖模塊
-
拼局模塊
-
個人模塊
-
后台模塊
一、認證模塊
1.1學生基礎信息認證模塊
-提供學生基礎信息驗證
1.2學生個人證件認證模塊
-提供學生個人證件圖片上傳
二、校友圈模塊
2.1簽到模塊
-提供用戶進行每日簽到
2.2帖子搜索模塊
-提供用戶進行全局模糊搜索論文
2.3帖子詳情模塊
2.3.1評論帖子
-用戶對帖子進行評論相關操作
2.3.2點贊帖子
-用戶對帖子進行點贊相關操作
2.3.3贊賞帖子
-用戶對帖子進行贊賞相關操作
2.3.4收藏帖子
-用戶對帖子進行收藏相關操作
2.3.5拉黑帖子發布者
-用戶對帖子發布者進行拉黑，不看他的相關帖子並且不與他私聊
2.3.6舉報帖子
-用戶對含有不正當內容的帖子進行舉報
三、消息模塊
3.1查看我的相關評論
-提供用戶查看與其帖子相關的評論
3.2查看我的相關點贊
3.2.1查看我的相關贊賞
-提供用戶查看與其帖子相關的贊賞
3.2.2查看我的相關點賞
-提供用戶查看與其帖子相關的點賞
3.3查看我的相關拼局
-提供用戶查看與其拼局相關的信息
3.4查看我的相關私聊
-提供用戶與其他用戶進行私聊
四、發帖模塊
4.1帖子發布
4.1.1根據主題發布帖子
-提供用戶根據主題帖子發布
4.1.2根據地址發布帖子
-提供用戶根據地址帖子發布
五、拼局模塊
5.1組局詳情
5.1.1加入組局
-用戶加入已創建好的組局
5.1.2評論組局
-用戶評論已創建好的組局
5.2篩選組局信息
-用戶根據條件顯示想看到的組局內容
5.3發起組局
-用戶創建新的拼局
5.4搜索組局
-用戶搜索關鍵詞相關組局
六、個人模塊
6.1個人數據模塊
6.1.1人品值記錄模塊
-顯示用戶的人品值數與人品值進出記錄
6.1.2個人收藏模塊
-顯示用戶的個人收藏記錄
6.1.3個人帖子模塊
-顯示用戶的個人帖子記錄
6.1.3個人評論模塊
-顯示用戶的個人評論記錄
6.2附加功能模塊
6.2.1新手幫助
-為用戶提供使用該軟件的新手幫助說明
6.2.2社區規范
-為用戶提供使用該軟件的社區規范說明
6.2.3逐夢樹洞
-為用戶提供私人的信息交流空間
6.2.4邀請校友
-為用戶提供邀請校友進行分享
6.3系統模塊
6.3.1設置模塊
-對軟件進行基礎設置
6.3.2關於我們
-了解軟件開發者相關信息和聯系方式
6.3.3意見反饋模塊
-對用戶使用軟件體驗進行反饋
七、后台模塊
7.1.1審核模塊
-對用戶的帖子評論圖片等信息進行內容審核
7.1.2維護模塊
-對軟件的一些基礎功能進行調整
功能模塊層次圖
ER圖
從用戶角度出發，尋找用戶擁有的屬性，尋找用戶與其他類（帖文、組局等）的關聯，確定之間的關系：1對多、1對1等，再補充其他類的擁有的屬性。
用戶和管理員部分
帖文(post)部分
組局部分
數據庫表結構
數據庫使用關系型數據庫。數據庫表結構設計在ER圖的基礎上，結合實體屬性的存儲方式，為各實體屬性賦予相應的數據類型。
此外，為表示ER圖中實體之間的一對多關系，數據庫表中使用新增外鍵屬性的方法對一對多的關系進行約束，例如帖子post與帖子的評論post_comment是一對多的關系，在post_comment中新增post_id屬性與對應帖子post的id屬性關聯，建立外鍵約束，表示帖子評論所屬的帖子，對帖子與帖子評論的一對多關系進行了刻畫和約束。ER圖中還出現了實體與自身的一對多約束，同樣，在數據庫設計時在表中建立了外鍵與自身關聯，例如，一條帖子評論下可能包含有多條評論（樓中樓），設計時新增pre_id外鍵關聯自身表的id屬性，建立外鍵，表示帖子評論所屬的上一級評論，對帖子評論與自身的一對多的關系進行了刻畫和約束。
ER圖中出現的多對多關系，考慮到要滿足范式減少數據冗余，關系型數據庫較難表示，與要對多對多關系進行轉換（實際在ER圖中已經轉換），新建一個額外的表，存儲多對多關聯，將多對多關聯分解為兩個一對多關聯，例如用戶和組局之間的多對多關系，新增組局人員表對多對多進行轉換，變為兩個一對多的關系。
以上兩種處理思路解決了系統的一對多和多對多約束。
為了符合一些行業規范，在各個表中新增加了gmt_create,gmt_modified對記錄創建時間和最近一次修改時間進行了存儲。還增加了deleted屬性用於實現邏輯刪除功能，方便后台管理查看記錄。
- 用戶表
| 名稱 | 解釋 |
|---|---|
| admittedYear | 畢業年份 |
| birthday | 出生年月 |
| certificateImageUrl | 用戶證件照 |
| city | 城市 |
| deleted | 邏輯刪除 |
| gmtCreate | 創建時間 |
| gmtModified | 修改時間 |
| id | 用戶ID(使用微信提供的openID) |
| isGraduated | 是否畢業 |
| province | 省份 |
| rpValue | 人品值 |
| school | 用戶學校 |
| sex | 性別(0為女，1為男，2為無) |
| status | 用戶狀態(0為未審核，1為已審核) |
| userIconUrl | 用戶頭像 |
| username | 用戶名 |
- 管理員表
- 黑名單表
| 名稱 | 解釋 |
|---|---|
| beUserId | 被拉黑用戶ID |
| deleted | 邏輯刪除 |
| gmtCreate | 創建時間 |
| gmtModified | 修改時間 |
| id | 黑名單ID |
| userId | 用戶ID |
- 組局表
| 名稱 | 解釋 |
|---|---|
| deleted | 邏輯刪除 |
| description | 組局描述 |
| gmtCreate | 創建時間 |
| gmtModified | 修改時間 |
| id | 組局ID |
| imageUrls | 圖片url鏈接 |
| partyTypeId | 組局類型ID |
| peopleCnt | 組局人數限定 |
| publisherId | 發布者ID |
- 組局評論表
| 名稱 | 解釋 |
|---|---|
| deleted | 邏輯刪除 |
| gmtCreate | 創建時間 |
| gmtModified | 最近一次修改時間 |
| id | 組局評論ID |
| idFrom | 評論者ID |
| information | 內容 |
| partyId | 對應組局ID |
| preId | 父評論ID |
| status | 評論狀態0(正常狀態）,1（舉報過多被掛起），2（已被刪除） |
- 組局成員表
| 名稱 | 解釋 |
|---|---|
| deleted | 邏輯刪除 |
| gmtCreate | 創建時間 |
| gmtModified | 最近一次修改時間 |
| id | 組局參與表ID |
| participantId | 參與者ID |
| partyId | 對應組局ID |
- 組局類型表
| 名稱 | 解釋 |
|---|---|
| deleted | 邏輯刪除 |
| gmtCreate | 創建時間 |
| gmtModified | 最近一次修改時間 |
| id | 組局類型ID |
| name | 組局類型名 |
- 帖文表
| 名稱 | 解釋 |
|---|---|
| deleted | 邏輯刪除 |
| gmtCreate | 創建時間 |
| gmtModified | 最近一次修改時間 |
| id | 帖文ID |
| imageUrls | 帖子圖片URL |
| message | 帖子文本內容 |
| postTypeId | 帖子類型ID，外鍵 |
| publisherId | 發布者ID，外鍵 |
| status | 帖子狀態：0(正常狀態）,1（舉報過多被掛起），2（已被刪除） |
- 帖文評論表
| 名稱 | 解釋 |
|---|---|
| deleted | 邏輯刪除 |
| gmtCreate | 創建時間 |
| gmtModified | 最近一次修改時間 |
| id | ID |
| idFrom | 發布評論用戶ID，外鍵 |
| message | 內容 |
| postId | 所屬帖子ID，外鍵 |
| preId | 所屬評論ID，外鍵 |
| status | 評論狀態：0(正常狀態）,1（舉報過多被掛起），2（已被刪除） |
- 帖文審核表
| 名稱 | 解釋 |
|---|---|
| deleted | 邏輯刪除 |
| gmtCreate | 創建時間 |
| gmtModified | 最近一次修改時間 |
| id | ID |
| idFrom | 發布評論用戶ID，外鍵 |
| postId | 所屬帖子ID，外鍵 |
- 帖文收藏表
| 名稱 | 解釋 |
|---|---|
| deleted | 邏輯刪除 |
| gmtCreate | 創建時間 |
| gmtModified | 最近一次修改時間 |
| id | ID |
| idFrom | 關注用戶ID，外鍵 |
| postId | 帖子ID，外鍵 |
- 帖文贊賞表
| 名稱 | 解釋 |
|---|---|
| deleted | 邏輯刪除 |
| gmtCreate | 創建時間 |
| gmtModified | 最近一次修改時間 |
| id | ID |
| idFrom | 發布評論用戶ID，外鍵 |
| postId | 贊賞用戶ID，外鍵 |
| amount | 贊賞數量 |
- 帖文類型表
| 名稱 | 解釋 |
|---|---|
| deleted | 邏輯刪除 |
| gmtCreate | 創建時間 |
| gmtModified | 最近一次修改時間 |
| id | ID |
| name | 帖子類型名 |
| pre_id | 帖子類型父類ID，外鍵 |
- 私聊表
| 名稱 | 解釋 |
|---|---|
| deleted | 邏輯刪除 |
| fromId | 發送用戶ID |
| gmtCreate | 創建時間 |
| gmtModified | 修改時間 |
| id | 私聊ID |
| message | 私聊信息 |
| toId | 接收用戶ID |
- 舉報表
| 名稱 | 解釋 |
|---|---|
| deleted | 邏輯刪除 |
| gmtCreate | 創建時間 |
| gmtModified | 最近一次修改時間 |
| id | ID |
| userId | 舉報用戶ID，外鍵 |
| postId | 被舉報帖子ID，外鍵 |
- 樹洞表
| 名稱 | 解釋 |
|---|---|
| deleted | 邏輯刪除 |
| fromId | 用戶ID |
| gmtCreate | 創建時間 |
| gmtModified | 修改時間 |
| id | 樹洞ID |
| message | 樹洞內容 |
類圖
UML 類圖用於描述系統中所包含的類以及它們之間的相互關系，幫助人們簡化對系統的理解，它是系統分析和設計階段的重要產物，也是系統編碼和測試的重要模型依據。一個好的類圖設計能夠給編碼開發一個好的開始。我們按照系統的功能模塊划分，將類圖設計部分分為4個部分單獨設計（用戶部分、管理員部分、貼文部分和組局部分），之后進行整合。當然，能夠這樣進行划分設計的前提是各個模塊之間的關聯並非很多，往往只是一個模塊和另一個模塊中的某個類有關聯。所以，模塊化的好處在於能夠更清晰地發現類和擬定類的方法，並且不至於使類圖過於龐大而影響最終的閱讀。
我們在類圖設計中結合了開發階段所利用的語言、框架、操作系統等等因素。在這些開發環境的基礎上組織我們的類。依據SpringBoot框架，我們將類分為Model，Dao，Service和Controller四大部分。其中，Model是系統中的實體類，負責規范數據結構，方便數據的傳輸和使用；Dao部分則為與數據庫交互的接口，一個Model往往對應一個Dao；Service類則是系統的處理核心，負責起系統的大部分計算；Controller類則為前端提供接口。我們遵循設計為開發原則，杜絕無用功。
此外，我們在類圖中加入了包，是類圖組織有序，更易於觀看
用戶類圖
發帖類圖
組局類圖
管理員類圖
系統安全
不同需求對安全產生不同的定義，安全對我們來說就是數據安全，即數據不被竊取，數據不被篡改，數據不被偽造。安全設計的核心是信任域的划分，而基於安全域的原子權限則是數據的堅實保護。原子權限正是這次安全設計的核心思路。
系統（平台）層面的安全
軟件運行所需的基礎環境既是此處的系統，包括以下內容：操作系統，WEB服務器中間件，軟件運行所需的程序語言環境。
在這個層面主要從這幾個方面進行防護：
- 最小服務，通過減少與外界的接觸面來降低入侵發生的可能性，只開放必要的服務端口
- 安全版本，使用各種應用的最新stable版本來防止入侵
- 合理的iptables設置，通過設置嚴格的出網規則來提高入侵的成本和難度
- 合理的配置，對於各種應用的配置不應當直接復制網上的demo，而應該了解每一個配置會產生的行為后進行設計
- Firewall的配置，禁止所有非TCP通信
- 安裝安全軟件識別已有特征的惡意軟件和行為
- 根據入侵常用手段配置蜜罐，使得我們有可能在被入侵的時候得知
- 數據與程序環境的分離，保證在得到程序環境的時候無法直接得到數據，對各種密鑰進行加密
- 合理的文件系統權限配置，保證得到網站權限無法修改網站代碼
框架層面的安全
框架層面的安全即我們為了快速開發使用的框架
在這個層面從以下方面做好防范：
- 不要從網上copy配置項，應當了解每一個配置會產生的行為，再進行框架的設置
- 對於自己所使用的框架接口應當清楚會產生怎樣的行為，而不是關注會產生怎樣的結果
- 在使用框架開發時應對開發環境和生產環境進行區分，在生產環境去除一切其他不必要的功能，比如報錯
代碼層面的安全
在開發時我們應當遵守以下簡單的規則進行安全防護：
- 簡單了解owasptop10 后進行開發
- 使用框架提供的或團隊提供的安全操作函數
- 在代碼開發時應遵守OWASP安全編碼指南
- 對所有web接口進行
- 在代碼上線前使用白盒安全掃描工具進行測試，比如codeql
- 一切用戶資源文件都上傳至OSS中
傳輸層面的安全
在數據傳輸我們使用以下方法進行防御：
- 部署CDN防止發現真實IP
- 負載均衡增加入侵難度
- 部署雲WAF防御惡意攻擊
- 配置訪問頻率防止DDOS和拆解攻擊
- 使用HTTPS加密傳輸數據
- 前端對敏感數據比如密碼使用ECDH密鑰交換+AES加密
客戶端層面的安全
在客戶端層面我們要做好以下防護：
- Csrf token 防止跨站請求偽造
- 驗證碼防止暴力拆解，資源濫用
- CSP防止惡意js腳本
- Httponly防止cookie竊取
安全設計結構圖
處於成本考慮，以docker 為單元進行服務隔離
權限設計
權限管理是所有后台系統的都會涉及的一個重要組成部分，主要目的是對不同的人訪問資源進行權限的控制，避免因權限控制缺失或操作不當引發的風險問題，如操作錯誤，隱私數據泄露等問題。
迄今為止最為普及的權限設計模型是RBAC 模型,基於角色的訪問控制。由於我們的記賬系統是為已注冊登錄的用戶提供服務
頁面權限
- 普通用戶 : 校友圈頁面，個人頁面，拼局頁面
- 認證用戶：校友圈頁面，個人頁面，拼局頁面
- 管理員用戶：認證驗證頁面，組局驗證頁面，貼文驗證頁面
功能權限
- 普通用戶：修改個人資料，查看校友圈內容，參與個人認證，參與簽到
- 認證用戶：修改個人資料，查看校友圈內容，參與個人認證，查看消息，發送帖子，發起組局，匿名帖文，參與簽到
- 管理員用戶：通過驗證，不通過驗證
遺留問題
審核機制
手動寫自動篩選功能，管理員在后期可以對這些帖文組局進行再篩查，從而做到自動化。同時發布相關公約約定，一旦發現違規行為將進行封號處理
認證機制
考慮到認證機制的要素過多但是同時不保證人員虛假，我們選擇使用拍攝學生證上傳，同時增強對數據方面的保護，保證人員的簡單性
匿名功能
匿名功能沒有作為我們的主打功能，但是是存在在我們的系統功能當中的，匿名發布消息需要消耗一定的人品值
本次作業貢獻
| 學號 | 工作內容 | 貢獻度 |
|---|---|---|
| 221801104 | 項目功能思維導圖及分析 | 10.2 |
| 221801125 | 文檔歸納，ppt，博客園文檔 | 11.6 |
| 221801209 | 系統安全性分析，系統權限分析 | 10.4 |
| 221801215 | 類圖，接口文檔，數據庫表，ER圖 | 11.9 |
| 221801222 | 類圖，接口文檔，數據庫表，ER圖 | 12.1 |
| 221801230 | 數據流圖，項目規划 | 10.4 |
| 221801231 | 功能模塊層次圖，接口文檔 | 11.3 |
| 221801321 | 類圖包圖，接口文檔，數據庫表，ER圖 | 11.8 |
| 221801411 | 泳道圖 | 10.3 |