日常6+1 ——項目系統設計與數據庫設計

作業概況

這個作業屬於哪個課程	<班級的鏈接>
這個作業要求在哪里	<作業要求的鏈接>
這個作業的目標	1.完成系統設計 2.完成數據庫設計 3.制作PPT以及文檔
結對學號	091700403 110700516 221701104 221701105 221701116 221701132 221701141
作業正文	<作業正文>
其他參考文獻	...

團隊項目預期開發時間安排

周期表

周數	團隊目標與產出
第一周	1.前端小組完成頁面框架建立，使用vue CLI3.0搭建起基本文件框架。 2.前端小組完成前台子系統和后台子系統的頁面基礎結構搭建，組件位置以及頁面結構正確。 3.后端小組完成各個代碼層級的建立、新建出接口文件、填充屬性名。 4.后端小組可以完成數據庫的鏈接與訪問，完成Mybatis的實體類強化與映射。
第二周	1.前端小組頁面內填充組件，新建各自負責頁面的UI組件。 2.前端小組將各自負責的頁面內功能模塊組件化，以便於各個模塊的復用。 3.前端小組美化CSS效果，可使用ElementUI等UI組件幫助美化。 4.前端小組完成頁面跳轉等頁面間邏輯，保證組件傳參正確。 5.后端小組填充接口邏輯代碼，完成各自負責頁面功能的邏輯處理。 6.后端小組完成內部接口填充，使得自身功能模塊能夠正常使用。
第三周	1.前端小組繼續美化頁面。 2.后端小組完成外部接口填充，使得前端傳參時可以正確調用並返回參數。 3.后端小組測試並完善基礎功能接口。
第四周	1.前端小組開始調用后端接口嘗試完成頁面渲染與效果調用。 2.后端小組將功能接口寫成詳細文檔交予前端小組。
第五周	1.前端小組鏈接成功后進行前端測試。 2.前端小組在第五周前必須完成完整性校驗，不允許非法信息輸入。 3.后端小組開始嘗試語音輸入/識圖輸入等功能API，編寫新的接口，完善功能。 4.后端小組嘗試編寫熱門算法，找到一個合適的算法以代替完全按照時間展示的帖子列表。
第六周	1.前后端小組收尾，保證程序基本功能運行正常，頁面效果符合人機交互的標准。 2.bug修改和后期維護。

甘特圖

如果看不清可以使用右鍵查看圖像查看大圖。

人員分工

學號	姓名	前/后端	分工內容
091700403	陳靜	后端	1.數據庫建立 2.時間軸頁面內功能模塊的邏輯代碼編寫 3.平台頁面內功能模塊的邏輯代碼編寫 4.以上頁面功能代碼層級設計。 5.以上頁面接口的填充。
110700516	林泠	前端	1.時間軸頁面UI布置 2.地圖界面UI布置 3.以上頁面的模塊組件化 4.以上頁面的頁面美化 5.以上頁面的數據接口調用以及相應渲染 6.前端測試
221701104	潘晨宇	前端	1.帖子頁面UI布置 2.個人主頁頁面布置 3.后台頁面布置 4.以上頁面的模塊組件化 5.以上頁面的頁面美化 6.以上頁面的數據接口調用以及相應渲染 7.前端測試
221701105	邵研	后端	1.個人主頁頁面內功能模塊的邏輯代碼編寫 2.管理員頁面的功能模塊的邏輯代碼編寫 3.以上頁面功能代碼層級設計。 4.以上頁面對外接口的填充。
221701116	陳炎	后端	1.帖子頁面內功能模塊的邏輯代碼編寫 2.地圖頁面的功能模塊的邏輯代碼編寫 3.以上頁面功能代碼層級設計。 4.以上頁面對外接口的填充。
221701132	林傑	前端	1.時間軸頁面UI布置 2.地圖界面UI布置 3.以上頁面的模塊組件化 4.以上頁面的頁面美化 5.以上頁面的數據接口調用以及相應渲染 6.前端測試
221701141	馬科學	后端	1.個人主頁頁面內功能模塊的邏輯代碼編寫 2.地圖頁面的功能模塊的邏輯代碼編寫 3.時間軸頁面的功能模塊和邏輯代碼編寫 4.以上頁面功能代碼層級設計。 5.以上頁面對外接口的填充。

圖表設計及思路

體系結構設計圖

思路：

​ 本次程序設計按照vue+SpringBoot+Mybatis+Mysql5進行。前端VUE是一個MVVM框架的漸進式模型框架，所以打算整個系統都按照MVVM結構進行。其中MODEL擁有數據，ViewModel處理數據，然后渲染View。MVVM是MVC的二次升級版。MVC會由於數據量的龐大導致C層過於臃腫，所以進化出了MVP和MVVM結構模式，為了更加貼合開發框架，實現前后端解耦和分離。通過MVVM的模型可以使得頁面-數據處理-數據解耦，實現前后端的分離開發，前端只需要調用后端的接口即可實現ViewModel的數據綁定，傳遞到頁面渲染。

功能模塊層次圖

思路：

​ 將系統分為前台子系統和后台子系統。后台子系統登錄者為管理員，前台子系統登錄者為普通用戶。管理員可以對帖子進行審核和刪除。依據功能的不同，划分為時間軸模塊、帖子模塊、地圖模塊、廣場模塊、登錄模塊。相應的模塊調用相應的功能模塊，形成H圖。

設計類圖

思路：

1、首先想到的是系統用戶類，一款軟件的設計最主要的便是從用戶的角度着想。軟件中除了使用的用戶還需要有管理員來管理這些用戶，以防一些意外的發生，所以再設計出用戶類和管理員類。這兩個類之間存在一部分相同的屬性和方法，所以共同繼承於系統用戶類。

2、其次是用戶能夠做什么：發帖。所以就需要一個分享帖的類，來描述分享帖的各類信息。而我們設計的分享帖中有一個Tag標簽會顯示在分享帖中，而且每個分享帖的Tag不止一個，所以，再需要一個Tag列表類和Tag類來保存信息。分享帖之所以叫分享帖，便是需要給其他人瀏覽，當然不僅僅是看看，其他人也會發表自己的看法，所以也就需要有評論類。以上只是一個分享帖的內容，然而用戶瀏覽分享帖不可能只有一個分享帖，也就需要一個帖列表類，來歸整一系列的分享帖，在這個帖列表中，可以切換類別，分別來瀏覽屬於自己的，自己關注的以及廣場的分享帖。最終這些分享帖的帖列表聚合成了整個分享平台類。

3、再者便是這款軟件的另一個主要設計功能：時間軸。用戶擁有着固定的四種時間軸，所以需要有一個時間軸列表來保存這四種時間軸。一種時間軸中有多個時間軸動態。所以這里創建時間軸列表類、時間軸類、時間軸動態類。

4、最后就是軟件主要的核心功能：直觀的地圖顯示。這便需要一個地圖類，在這之下再有三個子類：全國地圖、省內地圖、市內地圖。為了直觀地表現地圖上的信息，便需要一個渲染的接口去實現。全國地圖和省內地圖是地圖塊的染色，所以依靠氣泡數列表和區塊列表屬性即可。而市內地圖是氣泡的顯示顏色深淺去判斷分享帖多少的分布。所以在市內地圖分成多塊地區，一個地區對應一個氣泡，之后再依靠渲染的接口，改變氣泡的深淺，達到直觀顯示的目的。而我們也將實現搜索功能，這里的搜索功能將利用分享帖中Tag標簽，能夠提高搜索的准確性，而這個功能的實現也依賴於Tag搜索的接口。

以上便是所需要類的產生，之后再根據所需要保存的信息，與其他類圖交互所需要的信息，添加屬性和方法，直至完善整個類圖。

ER分析和表結構

以用戶表舉例（詳情見文檔）

思路：

1、從用戶出發，他可以創建分享帖和評論，並且可以創建多個，也就形成一對多關系。分享帖中對應着標簽和評論，一個分享帖可能有多個標簽和評論，所以也是一對多關系。

2、用戶擁有多個類別的時間軸，也形成一對多關系。用戶也可以創建動態，並且可以創建多個，也就形成一對多關系。一個時間軸內有多個動態，所以時間軸和動態也是一對多關系。

3、動態和分享貼只會屬於一個地區，一個地區內可能會有多個帖子發布，所以這里地區和動態與分享帖都是一對多關系。

4、在數據庫中關注列表中，存儲關注人ID和被關注人ID，但這里面存在着關注他人和被他人關注的關系，所以用戶擁有粉絲列表和關注列表，也都是一對多關系。

5、依據一對多或多對多關系設計表。帖子與評論是一對多，故評論表中加上帖子id進行關聯。用戶和時間軸是一對多，故在時間軸表中加上用戶id。時間軸和動態是一對多，故在動態表中加入時間軸id。帖子和標簽是一對多，故在標簽表中加入帖子id。用戶與用戶可以互相關注，故加了一個tb_user_follow表來記錄這種關系。

系統安全與權限：

(1) 后台過濾

后端設置過濾機制，使用過濾器對沒有注冊登錄用戶的請求進行攔截，不予放行，防止非法用戶惡意操作，只有經過常規途徑注冊並登錄的用戶才能使用系統。

訪問者	權限提供
用戶	評論、轉發、點贊、舉報帖子、查看時間軸等
管理員	審核帖子、凍結用戶

(2) 數據加密

對存儲和傳輸的數據進行加密處理，從而使得不知道解密算法的人無法獲知數據的內容。

(3) 防SQL語言注入

前端對輸入進行驗證，防止諸如“SELECT USER”等語句的輸入導致后台執行數據庫操作泄露數據庫中數據。

(4) 存取控制

通過用戶權限定義和合法權檢查確保只有合法權限的用戶訪問數據庫，所有未被授權的人員無法存取數據。 例如C2級中的自主存取控制(I)AC)，Bl級中的強制存取控制(M．AC)。

(5) 視圖控制

為不同的用戶定義視圖，通過視圖機制把要保密的數據對無權存取的用戶隱藏起來，從而自動地對數據提供一定程度的安全保護。

(6) 安全可靠的存儲

將數據庫配置在含有物理安全防護以及互聯網防護的雲服務器端上，避免物理損壞等意外事故。

思路:

1、防止未登陸的用戶對頁面進行訪問，需要對url和Session進行過濾，檢查是否登錄，如果未登錄不允許進入后續界面，所以需要對用戶進行過濾。

2、不同的用戶應該具有不同的權限，其中僅僅允許用戶和管理員刪除帖子，特別的，用戶僅能

3、防止對數據庫的直接攻擊，得到用戶的密碼等隱私信息。所以傳輸信息，保存隱私信息的時候采用加密算法保存。

4、前端防止因為沒有對輸入進行規范化處理，導致前端輸入SQL語句后，后端直接運行了輸入的語句，導致數據庫數據暴露。前端需要對輸入進行完整性和規范性校驗，完成后才允許下一步的功能，否則給出提示，以防止SQL注入攻擊。

5、為了防止不同層級的用戶看到不能看到的數據，則使用視圖，使得用戶只能看到自己對應權限的數據庫數據。

6、為了防止物理因素等情況導致的數據庫問題，選擇了大廠更安全的雲服務器，在防止攻擊上更可靠。

需求分析中的問題

• 設計類圖的時候考慮前端的類了嗎？

  在本次完善類圖的時候，除去前端所需要展示的帖子類、時間軸類、動態類、個人信息等等，新增了氣泡類和地區類，用以在地圖數據可視化功能模塊時，為前端所需要的組件類提供參考。由於其他類，如：導航欄類、側邊欄類、內容欄類等等不屬於我們這次WebApp的主要功能，所以在設計類圖的時候並沒有放進去。這些屬於視圖、UI等等的不在主要功能中的組件類我們放在了UIL（User Interface Layer）中，詳見系統設計文檔的第5章。

  

• 驗收標准、並發數、響應時間？

  驗收標准分為功能驗收標准和界面驗收標准，已放在需求分析文檔中，詳情見上次的需求分析文檔。

  並發數和響應時間這次也寫在了系統分析的文件中。詳見第九頁，3.2詳細性能需求分析。其中詳細介紹了系統所需要的性能以及我們使用的框架所需要的性能介紹。簡單回答並發數和響應時間的要求。在並發上，至少允許100個用戶同時訪問（不考慮掛起用戶），在並發的傳輸上要求盡量保證快速的傳遞效率。並且在后續氣泡的數量問題上，我們會定時刷新數量，保證異步更新。在響應性上，我們要求查詢時間響應需要少於5秒，查詢包括：顯示帖子，顯示數據化地圖，顯示時間軸以及正常的顯示功能。簡單的添加和修改響應不超過15s，復雜的不超過5mins。至於這些性能的要求是受限於我們的硬軟件，如我們的服務器是租用的百度雲服務器，帶寬僅1M，對數據的傳輸、並發上可能無法達到較高的層級。對於我們現在開發受限的條件，詳見第7頁2.1.3處，文檔解釋了四點我們現在開發所被限制的條件。

以上就是需求分析中所有的問題，如還有更一步細節的問題，詳見《Daily6+1軟件系統詳細設計說明書》

改進部分

1.對類圖、用例圖、數據流圖改進了。

上次的類圖、用例圖不足，這次補充了上次的類圖和用例圖、數據圖和流程圖。

其中類圖的改進見上。為了分析使用系統的角色以及角色對應使用的功能，我們又畫了用例 圖。再通過分析不同模塊之間的數據溝通過程，我們畫出了新的數據流圖以指導我們模塊之間 的交互。圖見下：

​

2.明確了需求的性能分析。

​ 對本系統的需求更加細化：除了上次的需求文檔中的功能需求。還分析了性能需求、資源需求、系統運行環境以及限制條件和接口分析。通過網上查閱相關的文檔，對其中的類目有了更深的了解。包括性能需求的系統、數據、接口、並發、框架等需求，資源的軟硬件需求，系統運行環境的軟硬件要求以及外部界面和內部界面接口分析等。相應的文檔見下系統設計第3章部分。

本次工作流程以及分工

詳見下甘特圖

貢獻度

學號	工作內容	貢獻度
091700403	數據庫基礎設計、功能模塊層次設計、層次代碼設計、接口設計、文檔編寫	16.5
110700516	搜尋模板、博客編寫、UML圖繪制	11
221701104	搜尋模板、UML圖繪制、系統結構、代碼結構等設計、文檔編寫、數據庫安全設計、PPT制作和展示	14.5
221701105	UML圖繪制、層次代碼設計、接口設計、文檔編寫	14
221701116	UML圖繪制、層次代碼設計、接口設計、ER圖繪制、文檔編寫	16.5
221701132	搜尋模板、博客編寫、UML圖繪制	11.5
221701141	層次代碼設計、接口設計、ER圖繪制、后端文檔整合、文檔編寫	16

github倉庫地址以及下載鏈接

• github團隊倉庫鏈接

• Daily 6+1_系統設計說明書.pdf，提取碼：zije

• Daily 6+1_數據庫設計說明書.pdf，提取碼：vfyr

• Daily 6+1_系統設計和數據庫設計答辯PPT.pdf，提取碼：zafz