團隊作業第四次—項目系統設計與數據庫設計
| 這個作業屬於哪個課程 | 2020春|W班(福州大學) |
|---|---|
| 這個作業要求在哪里 | 團隊作業第四次—項目系統設計與數據庫設計 |
| 團隊名稱 | RATE-MAX |
| 這個作業的目標 | 完善需求分析，新增系統設計、數據庫設計 |
| 作業正文 | 下文 |
| 其他參考文獻 | ... |
團隊項目的預期開發計划時間安排
| 時間 | 活動產出 |
|---|---|
| 階段1（4.7-4.11） 數據庫設計 |
系統及數據庫設計復審 sql文件及復審 項目計划時間及分工 自學技術 |
| 階段2（4.12-4.18） 軟件測試 |
環境配置 目錄結構約束 接口復審 服務器部署 自學技術 |
| 階段3（4.19-4.25） Alpha第一周 |
完成“個人中心”模塊 完成“私聊”模塊 測試上述兩個模塊功能 |
| 階段4（4.26-5.1） Alpha第二周 |
完成“廣場”模塊 實現管理員：查看列表 測試模塊功能 准備答辯事宜 |
| 階段5（5.3-5.16） Beta第一二周 |
Alpha功能完善 小模塊功能添加 細節調整 |
| 階段6（5.18-5.25） Beta第三周 |
完成“深夜食堂”模塊 測試模塊功能 |
| 階段7（5.26-6.2） Beta第四周 |
完成“漂流瓶”模塊 完成“廣告頁”模塊 測試模塊功能 實現管理員功能：封號、封聊天室、舉報處理 |
| 階段8（6.3-6.5） Beta第五周 |
優化 修補 |
團隊項目的預期開發計划分工安排
| 模塊 | 前端人員 | 后端人員 |
|---|---|---|
| 聊天模塊 | 林海峰 | 洪楷濱，陳煬 |
| 個人中心模塊 | 林露 | 李波 |
| 廣場功能模塊 | 陳如濱 | 黃毅，黃筱宇 |
| 管理員模塊 | 林露，陳如濱 | 李波，陳煬 |
| 深夜食堂模塊 | 林露，陳如濱 | 洪楷濱，黃筱宇 |
| 漂流瓶模塊 | 林海峰 | 黃毅 |
相關設計圖
體系結構圖
（本系統的設計主要是基於MVC設計模式，M代表模型Model，V代表視圖View，C代表控制器Controller。）
功能模塊層次圖
（分為普通用戶功能模塊和管理員功能模塊）
設計類圖
- 注冊登錄類
- 個人中心類
- 管理員類
- 廣場類
- 拓展部分類
- 朋友列表類
- 漂流瓶類
- 深夜食堂類
ER分析
（注：實線表示標識關系，虛線表示非標識關系。實心圓端所在的那端為一對多關系中的多的那端。）
表結構設計
系統安全+權限設計
-
防止用戶直接操作數據庫
用戶只能通過給定的外部接口操作數據庫：外部接口向內部接口傳遞參數，然后進行預編譯sql語句后才能操作數據庫，這從根本上杜絕了用戶直接操作數據庫的可能。 -
用戶賬號密碼的加密
賬號不加密，密碼后期進行相關加密技術進行加密（md5） -
權限設置
定義用戶的權限，限制個別用戶對某些功能的使用。如用戶在與人聊天是收到舉報並在管理員進行封號處理后，用戶有一段時間不能與他人進行相遇的朋友界面的對話。在某個聊天室的被管理員進行關閉時，用戶無權限訪問聊天室聊天。在動態頁面的某條動態收到管理員處理時，該條動態用戶無權限查看。 -
視圖控制
系統定義視圖，為不同的用戶定義不同的視圖，把數據對象限制在一定的范圍內， 通過視圖機制把要保密的數據對無權用戶隱藏起來。 -
信息存取控制
后期開發過后時間充裕的化進行對數據庫中有關表和字段信息的加密、解密。初步決定采用用對稱加密算法中的分組密碼算法DES實現。如果有更進一步的健壯性要求，采用三重DES、IDEA等加密算法。 -
保密安全設置
后台設置攔截器防止同一IP在短時間內進行大量的惡意請求，造成服務器資源緊張，癱瘓的現象。
后端設置過濾機制，使用過濾器對沒有注冊登錄用戶的請求進行攔截，不予放行，防止非法用戶惡意操作，只有經過常規途徑注冊並登錄的用戶才能使用系統。
問題回答&需求分析改進
補充說明
-
Q：QQ郵箱的漂流瓶玩法已經涼了好幾年了，你們的漂流瓶功能如何吸引用戶？
A：因為我們的項目主要功能主打聊天和匿名發言，談心還有不受生活拘束的自由自在的聊天，所以漂流瓶只是個額外的趣味性功能，能讓用戶閑暇時間能體會之前的漂流瓶的趣味，並不考慮用漂流瓶吸引用戶。 -
Q：有跟其他系統接入的情形嗎？
A：之前有考慮外部的系統的接入，主要是外部的信息屏蔽系統，短信系統，還有之后可留作拓展的舉報審核系統。 -
Q：那么在需求中是否有考慮他們與現有類的關系？或者數據流關系？
A：之前需求中僅僅只是考慮現有內部類的關系，將外部系統隔離在外，並未建立聯系，之后在類圖中有添加。如登陸模塊中與外部短信接口進行聯系，同時舉報也有響應的外部接口進行聯系。
數據流圖有相應的審核功能和身份驗證功能保證外部系統的交互。 -
Q：這個當初推行的是全匿名的聊天這個用戶的昵稱是怎么處理的？
A：自行設置 -
Q：每次聊天的時候都新建一個昵稱嗎？
A：是的 -
Q：是隨機產生的匿名昵稱嗎？
A：用戶自帶昵稱。
系統設計討論
-
P：用戶使用場景圖，好像面向對象課上有過類似的例子，登陸選課系統那個例子。記得是說登陸包括其他用況的話“登陸”用況的功能不單一，必須要了解系統的所有其他模塊才能描述清楚“登陸”用況，從維護的角度來看，會忘記對“登陸”用況進行修改。建議將登陸用況完全獨立於其他用況。
A：將登陸用況獨立出來。 -
P：發布動態以及評論的相關接口，表情和圖片應該和動態內容是一起傳遞的？
A：圖片先不設置單獨類型進行傳遞，采用與文字內容一起傳遞的方式 -
P：相遇的朋友 第七個 查看朋友信息 下面還有“不太清楚怎么設計”
A：添加舉報信息返回接口。 -
P：撈漂流瓶的傳遞參數問題。
A：開始設計時講手機號作為主鍵，后修改為用戶Id,並將所有的接口參數進行修改。 -
P：泳道圖的設置標簽？
A：添加設置標簽事件。
數據庫討論
-
P：用戶狀態需要字段嗎？
A：封禁 采用額外設置一個封禁表 -
P：本周標簽用id還是id名？
A：為了快速查看頁面，本周標簽用逗號分隔 -
P：本周標簽的個數？
A：本周標簽即可以添加也可以刪除直到有三個標簽，且允許為空。 -
P：過往標簽，是直接用上周標簽還是統計過去所有的標簽？
A: 包括所有的，按過往標簽次數來顯示。 -
P：用戶標簽表問題？如果我這周跟上周選擇了一樣的標簽,那主鍵不是有問題?
A：標簽表存放過往標簽，加一個標簽次數作為統計區分，同時刪除標簽類型字段。 -
P：朋友和信賴的概念問題？
A：這個“朋友”不是我們日常的那種相識的朋友,意思清楚就行了 -
P：深夜食堂類要有時間？
A：要有，存開始與結束時間。 -
P：評論表中被評論人id改成動態id?
A：修改 -
P：管理員功能？
A：查看用戶信息 、封號。 -
P：漂流瓶表應該關聯倉庫表？拋和撈的上限？
A：用戶信息表增加與漂流瓶倉庫表的關聯。用戶信息表記錄漂流瓶打撈與拋出個數（每日零點置零） -
P：漂流瓶編輯的關聯表需要有時間嗎？
A：加上edit_date字段。 -
P：舉報類和舉報表的確定？
A：舉報原因就設計成列表讓用戶選吧，舉報應該有類型，畢竟后台管理也要知道是啥類型的對象才能處理。所以是舉報類型,舉報項目+舉報內容,沒有圖片 -
P：我的錢包問題？
A：支付系統因為…是擴展功能中的擴展功能，估摸着時間不夠做不了。 -
P：聊天室搜索問題？
A：按聊天室名稱的模糊搜索。之后看情況添加標簽搜索。 -
P：數據庫名稱？
A：Hebdo。
本次工作流程、組員分工、組員貢獻度比例
| 學號 | 工作內容 | 貢獻度 |
|---|---|---|
| 221701123 | 體系結構設計；接口設計，安全健壯性設計； 編寫sql文件；預期開發計划安排；原型復審 |
13 |
| 221701101 | 設計與完善ER分析+表結構；制作評審表； 數據庫設計文檔整合復審 |
12.5 |
| 221701108 | 制作與完善數據流圖；編寫sql文件； 原型修改完善；類圖復審 |
12 |
| 221701120 | 功能模塊層次設計；編寫sql文件； 系統設計文檔復審 |
12.5 |
| 221701122 | 類圖修改完善；制作答辯PPT； sql文件復審 |
12 |
| 221701133 | 評審表設計；接口設計，安全健壯性設計； 預期開發計划安排；答辯PPT復審；答辯准備 |
13 |
| 221701139 | 接口設計，安全健壯性設計；預期開發計划安排； 設計項目開發技術及版本約束sql文件復審 |
13.5 |
| 221701202 | 制作泳道圖；編寫數據庫設計文檔引言； 數據庫設計文檔整合復審；撰寫隨筆 |
11.5 |
github倉庫及文件下載鏈接
github倉庫：sevenDays
RATE-MAX_系統設計說明書
RATE-MAX_數據庫設計說明書
RATE-MAX_系統設計和數據庫設計答辯PPT