作業基本資訊
| 這個作業屬于哪個課程 | 2021春軟體工程實踐|W班 |
|---|---|
| 這個作業要求在哪裡 | 團隊作業四——資料庫設計和系統設計 |
| 團隊 | Growing light |
| 這個作業的目标 | 完成資料庫和系統設計 制作《資料庫設計說明書》和《系統設計說明書》 團隊項目的預期開發計劃時間安排和分工 |
| 其他參考文獻 | 《系統設計說明書》《資料庫設計說明書》國标規範文本 和《建構之法》 |
團隊項目的預期開發計劃時間安排
| 時間 | 活動産出 | 裡程碑 |
|---|---|---|
| 第一周 (4.18~4.24） 資料庫和系統設計 | 系統設計說明書 資料庫設計說明書 系統設計和資料庫設計答辯PPT 項目預期開發計劃安排和分工 | 資料庫和系統設計完成 |
| 第二周 (4.24~5.1) Alpha第一周 | 使用者子產品 讨論子產品 首頁 登入注冊子產品 測試子產品功能 | |
| 第三周 (5.1~5.7) Alpha第二周 | 背景子產品 捐贈子產品 個人中心子產品 | Alpaha版本完成 |
| 第四周 (5.8~5.15) 軟體評測 | 進行軟體評測 | |
| 第五周 (5.15~5.21) | 完成軟體評測 準備答辯相關 | 軟體評測完成 |
| 第六周 (5.22~5.29) Beta第一周 | Alpha版本功能完善 完善個人中心子產品細節 進行前後端整合 | |
| 第七周 (5.29~6.6) Beta第二周 | 前後端整合後前端測試 添加全局檢索功能 添加視訊播放功能 測試以上功能 | |
| 第八周 (6.6~6.13) Beta第三周 | 添加視訊推薦算法 繼續完善功能 測試功能 | |
| 第九周 (6.13~6.18) Beta第四周 | 測試 優化 後期維護 | Beta版本完成 |
團隊項目的預期開發計劃分工安排
| 學号 | 姓名 | 前後端 | 分工 |
|---|---|---|---|
| 221801424 | 蘇傑陽 | 前端 | 前端登入注冊子產品、首頁、個人中心子產品、視訊推薦算法子產品 |
| 221801428 | 楊朕炫 | 後端 | 後端使用者子產品、視訊播放功能 |
| 221801133 | 楊思雨 | 前端捐贈子產品及附屬元件 | |
| 221801423 | 陳起 | 後端讨論子產品 | |
| 221801435 | 齊易捷 | 後端捐贈子產品、視訊推薦算法 | |
| 221801405 | 潘增滢 | 前端登入注冊子產品、首頁、個人中心子產品 | |
| 221801415 | 張富源 | 前端讨論子產品及附屬元件、背景子產品及附屬元件 | |
| 221801204 | 黃偉源 | 後端背景子產品 | |
| 221801412 | 劉曉君 | ||
| 221801426 | 林澤坤 | 團隊部落格、前端個人中心子產品 |
相關設計圖
體系結構圖
思路：使用者首先與View層進行互動，View層由Vue架構實作，其中一個頁面包含多個Component，即Component元件為頁面組織的最小單元；使用者點選頁面之後，系統發送請求到Controller層，該層主要負責具體業務子產品流程的控制，此層要調用到Service層的接口去完成業務，針對不同的業務流程有不同的控制器；Service層主要負責某個具體業務的邏輯設計，我們調用service接口進行業務處理，service調用到已經定義的Mapper層的接口，該層的封裝有利于提高通用業務邏輯的獨立性和重複利用性；Mapper層負責資料的持續化存儲，mapper層直接與資料庫打交道（執行SQL語句），将資料庫中的記錄組裝成Model對象，并将對象傳回給Service層；Model層即為系統中的實體類，其屬性和資料庫中的字段基本保持一緻。
各層的互動：
功能子產品層次圖
（根據業務和功能，将系統的邏輯結構劃分為平台功能子產品和背景功能子產品）
類圖
總覽（可以右鍵打開圖檔放大看）
CourseVideo視訊課程類
該類描述一個使用者上傳的視訊，主要屬性包括了視訊id、視訊标題title、視訊簡介info、上傳視訊的使用者id、視訊上傳時間、視訊位址url（url為數組，代表使用者分p上傳視訊，即一次上傳多個子視訊）、視訊播放數量played_num、視訊狀态status（枚舉值，包括未稽核、稽核未通過、稽核通過）、視訊收藏數量liked_num、視訊封面位址、視訊類型Type（啟蒙、國中、國小等，一個視訊類型包含多個标簽Tag，例如國文、數學、英語等）。
VideoComment視訊評論類
p.s. 這裡需要說明一下id、to_comment、below_comment的差別。Id是每條評論的唯一辨別符，也就是評論表的主鍵。to_comment和below_comment都是評論表的外鍵，指向另外一條評論的id，也就是說這兩個外鍵指向評論表本身。
to_comment的設計主要考慮到以下情況：
評論1：XXXXXX
評論2 回複 評論1： XXXXX
這裡評論2的to_comment就是評論1的id。
而below_comment的設計主要考慮到以下情況：
評論1: XXXXX
評論2: XXXXX
評論3：XXXXX
評論4：XXXXX
即考慮到評論呈現一種樹形結構，那麼這裡的評論2的below_comment就是評論1的id，評論4的below_comment就是評論3的id。
CourseWare課件類
該類描述了每個課件所需要的資訊，主要的屬性有：課件id、課件下載下傳url、課件的名字name、課件所屬的視訊id。視訊和課件是一對多的關系，一個視訊對應多個課件。
Post文章類
該類描述了每個文章所需要的資訊，主要的屬性有：文章id、文章标題title、 帖 子簡介content、文章建立的時間createTime、釋出文章的使用者id fromUser、文章的 類别、文章的曆史浏覽人數view、文章評論數量commentNum、文章封面位址face。
文章與視訊類共用一個Type類型。
VideoPostRecord文章視訊關聯類
該類為CourseVideo視訊和Post文章的關聯類，主要用于在每個視訊的旁邊推薦相 關文章。該類有兩個屬性，分别對應文章的id和視訊的id。
User使用者類
該類描述了系統中每個使用者所需要的資訊，主要的屬性有：使用者id、使用者名字 user_name、 登入密碼password、使用者簡介introduction、使用者頭像位址avatar_url、 使用者年齡age、使用者性别gender、使用者手機号mobile、使用者郵箱email、以及使用者在系 統中所扮演的角色roles。
Permission權限類和Role角色類
本系統使用RABC權限控制，RBAC（Role-Based Access Control，基于角色的通路 控制），就是使用者通過角色與權限進行關聯。簡單地說，一個使用者擁有若幹角色，每一 個角色擁有若幹權限。這樣，就構造成“使用者-角色-權限”的授權模型。在這種模型中， 使用者與角色之間，角色與權限之間，一般者是多對多的關系。圖中User類為使用者類，User 類擁有多個Role類的執行個體，而一個Role類又擁有多個Permission類的執行個體。
CollectionRecord使用者收藏記錄類
該類記錄了使用者收藏的視訊，擁有屬性有：使用者id和視訊id。
VoluntaryActivity捐贈志願活動類
該類描述了一個捐贈活動所需要的資訊，主要屬性有：活動的id、活動名稱name、 活動簡介introduction、發起人id、開始時間start_time、結束時間end_time、活動 地點location、活動的類型、捐贈總數、活動的狀态、活動封面的位址、以及該活動所 擁有的參加記錄（ActivityRecord數組）。
ActivityRecord活動記錄類
該類作為VoluntaryActivity和User的中間類，記錄每個使用者所參加的活動，主要 屬性包括使用者id、活動的id、捐贈數量、捐贈時間。
視訊推薦算法
16年的時候，谷歌公開了YouTube的推薦算法，Deep Neural Networks for YouTube Recommendation，論文位址：https://www.sci-hub.ren/10.1145/2959100.2959190。 該論文采用了深度學習算法，在效果上超越了最常用的矩陣分解算法。整個推薦架構分為兩部分，召回和排序。
召回算法（candidate generation，候選産生），從視訊物料庫中篩選出幾百個視訊。因為計算量大，是以召回算法不可能也沒必要采用所有特征，是以召回算法隻采用了使用者行為和場景特征。
排序算法使用了更多的特征，給每個候選視訊計算一個分數，并且按照分數從高到低排序，從幾百個視訊裡邊再篩選和排序出幾十個視訊推薦給使用者。
召回算法
召回算法模型架構如下圖
召回階段（candidate generation）利用使用者的曆史觀看視訊資訊、曆史搜尋資訊、使用者特征資訊和視訊存在時間等訓練神經網絡，得到一個權重矩陣，該權重矩陣與視訊資訊向量做内積，得到每個視訊的推薦分數，選最大的N個進行召回。（具體請參考設計文檔）
排序算法
排序算法架構如下圖
排序模型和召回模型結構上非常類似，但在訓練目标和輸入上稍有不同。輸入是使用者特征資訊以及單個視訊的特征，預測目标為期望觀看時間，訓練方式采用權重邏輯回歸，負樣本的label為0，正樣本的label為根據使用者觀看時間設定權重weight，當觀看時長較長時則label值更大，這樣就區分了樣本的優劣。rank模型在預測時直接輸出的e(wx+b), 即期望觀看時間，再根據期望觀看時間确定推薦順序。
ER分析
（可以右鍵打開圖檔放大看）
表結構設計
使用者表Users
課程表Course
讨論表Posts
類型表type
記錄檔表operation_logs
評論表post_comment與course_comment
（因兩張表結構類似，故以post_comment表為例）
tag表
course_tag關聯表
permission表
post_course表
post_tag表
role表
role_perm表
user_collection關聯表
user_role關聯表
user_donate關聯表
donate_activity表
donate_record表
comment_message表
course_material表
系統安全和權限設計
1、資料加密
對儲存的密碼等資料進行MD5不可逆加密，確定使用者資料不會被洩漏。
2、使用者權限判斷
後端會根據使用者角色開放相應權限的接口，確定不讓使用者跨權限調用接口，不合法修改資料庫，確定資料庫每次修改或存儲都是正确的操作。
3、SQL防注入
後端資料庫互動架構會使用SQL預編譯的方式，防止惡意使用者輸入非法sql語句對資料庫資料造成損壞。
4、確定資料有效
前端會對使用者輸入的資料進行校驗，確定資料資料有效，符合規定。同時，後端接口會再一次判斷資料是否有效，防止有些使用者繞過前端使用者界面控制，使用第三方網絡請求工具，如Postman，RestTemplate等上傳不正确的資料，造成資料存儲錯誤。
5、事務控制
後端接口在所有涉及資料庫存儲，修改的控制器方法中都加入了事務控制，防止因為接口發生錯誤，導緻資料庫操作無法復原，造成不必要的麻煩。事務傳播方式采用REQUIRED方式，若該操作不處于事務中則建立一個事務，確定所有資料操作都處于事務控制中。
上次作業的Q&A及改進
Q&A
1、如何将活動記錄聚合到志願活動當中？
作為屬性已添加。Growing light——資料庫設計和系統設計
2、能否添加一個課程，對一系列的視訊進行統一管理？
由于再添加課程類太過于複雜（還需要實作配套的課程管理功能），是以這裡采用簡單處理，即将視訊類的url設定為數組，即允許對視訊進行分P（分成子視訊），以此達到對于系列視訊的管理效果，這裡課程的簡介，相當于CourseVideo裡的info屬性。Growing light——資料庫設計和系統設計
3、關于使用者類中包含了對于收藏記錄的操作的問題。
已将操作移至收藏記錄類，作為其靜态方法，保證了封裝性。Growing light——資料庫設計和系統設計
改進
将評論類改成用組合設計模式
評論類為何要使用組合模式？
因為評論是一個樹形結構，一個評論下面可能包含多個評論，用組合設計結構可以友善對于評論樹的操作.
本次工作流程、組員分工、組員貢獻度比例
流程圖
本次分工及貢獻度
| 工作内容 | 貢獻度 | |
|---|---|---|
| 系統設計說明書接口設計，引言，整合 | 11 | |
| 資料庫設計說明書設計，整合 | ||
| 系統設計說明書子產品設計 | ||
| 資料庫設計說明書ER圖，ppt編寫 | ||
| 系統設計說明書類圖設計，體系結構 | ||
| 系統設計說明書整合，修訂 | 8 | |
| 系統設計說明書概述，子產品設計 | ||
| 資料庫設計說明書結構圖 | ||
| ppt編寫，答辯 | 12 | |
| 部落格編寫 | 9 |