團隊作業第四次—項目系統設計與資料庫設計
| 這個作業屬于哪個課程 | 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檔案； 系統設計文檔複審 | |
| 221701122 | 類圖修改完善；制作答辯PPT； sql檔案複審 | |
| 221701133 | 評審表設計；接口設計，安全健壯性設計； 預期開發計劃安排；答辯PPT複審；答辯準備 | |
| 221701139 | 接口設計，安全健壯性設計；預期開發計劃安排； 設計項目開發技術及版本限制sql檔案複審 | 13.5 |
| 221701202 | 制作泳道圖；編寫資料庫設計文檔引言； 資料庫設計文檔整合複審；撰寫随筆 | 11.5 |
github倉庫及檔案下載下傳連結
github倉庫：sevenDays
RATE-MAX_系統設計說明書
RATE-MAX_資料庫設計說明書
RATE-MAX_系統設計和資料庫設計答辯PPT