RATE-MAX——項目系統設計與數據庫設計

團隊做業第四次—項目系統設計與數據庫設計

這個做業屬於哪一個課程	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