目錄
- 作業基本資訊
- 團隊項目的預期開發計劃時間安排
- 團隊項目的預期開發計劃分工安排
- 設計圖與設計思路
- 體系結構設計
- 功能子產品層次
- ER分析
- 表結構設計
- 設計類圖
- 後端類圖
- 前端類圖
- 前台
- 背景
- 系統安全與權限設計
- 系統安全設計
- 背景安全設計
- 資料庫安全設計
- 小程式功能子產品安全設計
- 權限控制設計
- 系統保護設計
- 系統安全設計
- 需求分析的改進部分和過程
- 問題
- 改進部分與過程
- 工作流程、組員分工、組員貢獻度比例
- 工作流程
- 組員分工與貢獻度比例
- 附件連結
- github團隊倉庫連結
- 發際線和我作隊_系統設計說明書.pdf
- 發際線和我作隊_資料庫設計說明書.pdf
- 發際線和我作隊_系統設計和資料庫設計答辯PPT.pdf
這個作業屬于哪個課程 | 2021春軟體工程實踐|W班(福州大學) |
---|---|
這個作業要求在哪裡 | 作業要求 |
這個作業的目标 | 編寫《系統設計說明書》《資料庫設計說明書》,完成答辯撰寫部落格,包含團隊項目的預期開發計劃時間安排和分工安排。 |
其他參考文獻 | 《建構之法第三版》《軟體工程》《系統設計說明書》國标規範文本《資料庫設計說明書》國标規範文本 《資料庫系統概論》 本項目的《需求分析報告》 |
本周作業完成後,團隊項目将進入沖刺階段,以下是我們小組具體每周的計劃安排
時間段 | 任務 | 備注 |
---|---|---|
第九周 | 實作小程式登陸界面及基本架構搭建 | |
4.26-5.2 | 背景管理系統界面基本架構搭建 | |
後端登入接口實作 | ||
學習使用echarts以及地圖元件api | ||
再院樓架設定點攝像頭收集資料 | 地點因實際情況确定 | |
設計識别模型,收集資料集 | ||
第十周 | 模型設計I | 準确率≥50% |
5.2-5.9 | 實作擷取使用者登入記錄、小程式通路情況接口及圖表 | |
實作停車查詢功能 | ||
實作散點熱力圖初步展示停車情況 | ||
釋出V1.0版本 | 釋出日期根據alpha沖刺實踐彈性浮動 | |
第十一周 | 思考V1.0版本所存在的不足之處并糾正 | 優先執行 |
5.10-5.16 | 隊内反思會+團隊互評 | 同上述任務優先級一緻,及時處理開發過程中暴露的問題 |
後端實作公告子產品、回報子產品接口 | ||
第十二周 | 小程式端完善個人中心及使用者回報子產品 | |
5.17-5.23 | 優化UI互動 | |
訓練模型II | 不斷收集資料集,提升準确率至60% | |
第十三周 | 嘗試實作路線導航 | |
5.24-5.30 | 伺服器負載均衡優化 | |
模型訓練III | 不斷收集資料集,提升準确率至65% | |
第十四周 | 加強伺服器安全性 | |
5.31-6.6 | 加強登入驗證 | |
加強接口隐蔽性 | ||
第十五周 | 背景資訊脫敏加密 | |
6.7-6.13 | 完善路線導航推薦 | |
釋出V2.0版本 | 釋出日期根據beta沖刺時間彈性浮動 | |
第十六周 | 結題 | |
6.14-6.20 | 隊伍總結+個人總結 | |
大吃一頓 |
開發流程中可能有些周任務較為輕松,這是為了讓隊員有更多的彈性時間來充電,專心于考試或者自己的私事。過于平均的工作量可能會使得一段時間内壓力得不到緩解,效果适得其反。
成員 | 方向 | 具體 |
---|---|---|
李宇琨 | 前/後端 | 圖表資料結構設計 |
系統安全性實作 | ||
小程式端地圖導航實作 | ||
張福榮 | 後端 | 資料集任務下發 |
模型設計、訓練、優化 | ||
林浩然 | 攝像頭相關資料結構、接口設計 | |
rtmp伺服器搭建、redis伺服器搭建 | ||
檔案上傳 | ||
伺服器負載均衡 | ||
宋家銳 | 圖表資料接口實作 | |
背景管理系統圖表互動 | ||
梁達毅 | 使用者回報接口實作 | |
小程式端圖表互動 | ||
武雍易 | 背景管理系統接口實作 | |
資料庫維護 | ||
陳樂曦 | 前端 | 背景管理系統界面、互動實作 |
小程式端界面、互動優化 | ||
呂慶炜 | 小程式端地圖規劃與應用 | |
散點熱力圖實作 | ||
李耕 | 小程式端界面、互動實作 | |
小程式端圖表實作 | ||
李榮臻 | ||
小程式架構設計思路
1.視圖層和邏輯層分離,通過資料驅動,事件互動,不直接操作DOM。
2.邏輯層負責邏輯處理、資料請求、接口調用等。
3.視圖層負責渲染頁面結構。
4.JSBridge下架起上層開發與Native(系統層)的橋梁,使得小程式可通過API使用原生的功能,且部分元件為原生元件實作,進而有良好體驗。
5.視圖層與邏輯層通過資料和事件進行通信,邏輯層提供資料給視圖層。

Web架構設計思路:web總體采用B/S架構。
技術架構設計:
功能子產品層次設計思路:大塊分為兩個子產品,一個是背景管理者功能子產品,另一個是小程式使用者功能子產品,兩個大子產品均是根據使用功能的類别進行劃分,如圖示相關資料查詢則劃分為資料可視化子產品,具體劃分見下圖
E-R設計思路:先局部後全局
1.首先對使用者需求進行綜合,歸納,抽象出實體及其屬性,要注意能作為屬性的盡量作為屬性而不要劃為實體;
2.找出實體間的聯系(作為屬性的資料項不能再用其他屬性加以描述,也不能與其他實體或屬性發生聯系),形成局部E-R圖;
3.将局部E-R圖合并成全局E-R圖,合并過程要取消沖突(屬性沖突,命名沖突,和結構沖突),修改重構消除備援。
表結構設計思路:
确定資料庫實體及其構成,将E-R圖轉化為關系模型,這個過程要處理概念結構設計中實體間一對多(多對一)、多對多聯系。同時為每個有需要的表都設計了外鍵,保證關聯的那個表發生修改時,對應的表都能級聯修改,最後映射為資料庫。
- 管理者表(admin)
發際線和我作隊——項目系統設計與資料庫設計 - 角色表(role)
發際線和我作隊——項目系統設計與資料庫設計 - 權限表(authority)
發際線和我作隊——項目系統設計與資料庫設計 - 公告表(notice)
發際線和我作隊——項目系統設計與資料庫設計 - 回報表(feedback)
發際線和我作隊——項目系統設計與資料庫設計 - 狀态表(status)
發際線和我作隊——項目系統設計與資料庫設計 - 圖檔表(feedback_picture)
發際線和我作隊——項目系統設計與資料庫設計 - 地點表(device)
發際線和我作隊——項目系統設計與資料庫設計 - 地點擁擠情況表(crowd_situation)
發際線和我作隊——項目系統設計與資料庫設計 - 管理者-回報表(admin_feedback)
發際線和我作隊——項目系統設計與資料庫設計 - 管理者-公告表(admin_notice)
發際線和我作隊——項目系統設計與資料庫設計 - 管理者-角色表(admin_role)
發際線和我作隊——項目系統設計與資料庫設計 - 權限-角色表(authortiy_role)
發際線和我作隊——項目系統設計與資料庫設計
設計思路:首先通過研究問題域發現了管理者、使用者、公告和回報類對象,再通過确定系統邊界找出了公告清單和回報清單類對象,然後深入需求分析,得到角色、權限、狀态、回報圖檔、地點、地點擁擠情況類對象,其次定義對象的屬性和操作,最後建立對象間的關系,對于多對多關聯關系應該通過增加中間類進行解決。
為使系統資料安全得到保障,系統穩定可用,我們應當對系統進行全面保護。
背景隻能夠管理者登入,我們使用SpringSecurity來進行管理者的權限管理。通過SpringSecurity來對使用者進行區分、驗證和授權,這樣還保證了背景登入的安全性。
對資料庫表進行資料備份。使用mybatis架構,由于mybatis啟用了預編譯,在sql執行前,會先将SQL語句發送給資料庫進行編譯;執行時,直接使用編譯好的sql,替換占位符“?”。因為SQL注入隻能對編譯過程起作用,是以這樣能夠很好的避免sql注入問題。使用PBKDF2對密碼進行哈希處理,它将僞随機函數與鹽值一起應用于輸入密碼,并重複多次此過程以生成派生密碼,然後可以将該密鑰作用加密密鑰後續操作中。這種 方式能夠解決md5加密,簡單密碼被人截取後進行比對,其他使用者的密碼被破譯的問題。
對于普通使用者來說,微信小程式是唯一的入口,是以我們設計隻有使用者通過微信登入授權後才能後使用所有的功能。
權限控制設計思路
本系統背景的管理采用基于角色的通路控制,也就是将使用者通過角色與權限進行關聯。一個使用者擁有若幹角色,每個角色擁有若幹權限,由此構成了“使用者-角色-權限”的授權模型。
在本系統中,背景管理具有公告管理、資料監視、回報管理等子產品,對于每個子產品又有不同的功能,每個功能可視為一個權限,角色可以了解為一定數量權限的集合、權限的載體。要給背景的管理者授予一定的權限,不需要直接将權限授予管理者,而是将角色賦予該管理者。
以下是本系統背景權限管理的示意圖
以下是權限控制子產品的類圖設計
資料庫權限部分的設計表,我們将使用者、角色、權限分離,然後通過使用者角色對應表和角色權限對應表實作使用者與角色對應,角色與權限對應,進而做到使用者與權限間接對應。這樣不僅保證了有好的拓展性,也保證了健壯性。
我們的産品為使用者提供的功能主要是檢視資訊,使用者需要進行的操作是非常少的,是以在高并發的情況下也不會出現重要資料丢失的情況,最壞的情況也就是使用者加載資訊緩慢或加載不出資訊。我們打算通過使用更高帶寬的伺服器和使用多台伺服器進行負載均衡來改善這個問題。
Q1:類圖中使用者類的操作不能直接用用例作為操作
A:需求分析的時候将類對象與參與者混淆,導緻直接将用例作為類的操作。本階段,通過複習uml相關知識,将兩者區分開來,修改了對應類圖。
Q2:分析類圖不需要出現接口類
A:已在改進的類圖中删除接口類并另外展示接口
改進後的類圖已經在設計類圖部分展示,根據老師的意見新增了地點和地點擁擠情況類圖
設計的類圖中删除了接口類,在本項目的《系統設計說明書》中有對接口的較長的描述,可以在附件中檢視。
點選檢視GitHub文檔上傳記錄
參照第一次團隊作業時制定的績效考核方案計算評分貢獻,詳見-->
學号 | 工作内容 | 貢獻度 |
---|---|---|
221801329 | 設計資料流圖和功能子產品圖,安排未來周計劃與分工 | 10.4% |
221801312 | 硬體環境和開發環境整理,總體架構和技術架構設計,設計接口文檔 | |
221801315 | 泳道圖和模型環境配置 | |
221801316 | 後端類圖,資料庫設計,權限管理設計思路 | 9.9% |
221801123 | 後端類圖,資料庫設計,資料庫設計說明書,ER+表結構設計思路 | 10.9% |
221801337 | 設計資料庫,類圖,接口文檔 | |
221801303 | 後端類圖與系統安全設計 | 8.3% |
221801238 | 設計背景類圖與小程式類圖,設計接口文檔 | |
221801406 | 功能子產品設計背景部分,PPT制作與部落格撰寫 | 9.4% |
221801427 | 功能子產品設計前台部分,系統設計說明書整合、評審表 |
- 點選檢視與下載下傳