| 這個作業屬於哪個課程 | <2020 春 W 班 (福州大學)> |
|---|---|
| 這個作業要求在哪里 | <作業要求> |
| 這個作業的目標 | 系統設計和數據庫設計 |
| 作業正文 | <作業正文> |
| 其他參考文獻 | <《構建之法》> |
part.01 團隊預期開發計划時間安排
在完成本周的系統設計和數據庫設計的作業之后，將進入代碼實現部分。我們的計划安排如下：
| 時間 | 安排 |
|---|---|
| 04.12-04.19 | |
| 參考開源的優秀項目，完成項目的搭建，初步決定采用的第三方庫並完成導入和測試。 | |
| 04.20-04.26 | |
| 后端：初步實現發布任務、失物招領、物品租賃三個模塊的接口。 | |
| Web前台：初步實現發布任務、失物招領、物品租賃三個模塊的界面。 | |
| Web后台：初步實現發布任務、失物招領、物品租賃三個模塊的界面。 | |
| Android：初步實現發布任務、失物招領、物品租賃三個模塊的界面。 | |
| 04.27-05.03 | |
| 后端：完善項目，並將后端部署到服務器，協助前端完成數據的交互。 | |
| Web前台：完善項目，與部署在服務器的后端進行交互。 | |
| Web后台：完善項目，與部署在服務器的后端進行交互。 | |
| Android：完善項目，與部署在服務器的后端進行交互。 | |
| 05.04-05.10 | |
| 后端：根據開發過程遇到的問題，對項目的細節進行優化。 | |
| Web前台：優化項目，並將Web端部署到服務器。 | |
| Web后台：優化項目，並將Web端部署到服務器。 | |
| Android：優化項目，並將Android端打包，發布到應用商店。 | |
| 05.11-05.17 | |
| 測試，小范圍推廣，優化，針對bug版本更新。 | |
| 05.25-05.31 | |
| 測試，大范圍推廣，維護，針對bug版本更新。 | |
| 05.18-05.24 | |
| 根據用戶反饋，評估項目的合理性，對項目的功能進行調整和擴充，版本更新。 | |
| 06.01-06.07 | |
| 維護 |
part.02 預期開發計划分工安排
| 學號 | 安排 |
|---|---|
| 221701412 | 主導完成后端的架構，發布任務功能模塊的開發。 |
| 221701414 | 負責Android部分的開發。 |
| 221701417 | 深入到潛在用戶中進行調研、推廣、收集用戶反饋。參與前端界面的設計。 |
| 221701418 | 負責Web前台的開發。 |
| 221701420 | 負責Web后台的開發和維護。協助Web前台開發。 |
| 221701429 | 熟悉前后端的工作進度，參與后端數據庫的開發，接口文檔的撰寫和維護。 |
| 221701431 | 主導數據庫的設計和維護，完成后端失物招領和物品租賃模塊。 |
| 221701439 | 對前后端的程序進行充分的測試，生成測試文檔。 |
part.03 設計圖及描述
體系結構設計
功能模塊層次圖
設計類圖
ER 分析圖
表結構設計
（列舉部分）
用戶表
管理員表
失物招領物品表
評論表
敏感詞表
舉報表
系統安全和權限設計
本數據庫經由使用者名稱及密碼認證使用者的登入，若使用者名稱有效且密碼正確則建立聯機。同時，登入者們有三種不同的數據庫存儲權限。
1.擁有者權限:對於數據庫、使用者或對象建立所在的空間，系統將擁有權授予該空間的擁有者。擁有者為建立新對象的使用者或數據庫(在 CREATE DATABASE / CREATEUSER 陳述的 FROM 子句中指定)。例如，數據表的擁有者具有隱含的權限，能夠准許(GRANT)它自己對於其所擁有的數據表有 SELECT 的特權。
2.自動產生的權限:此為系統自動授予數據庫、使用者或對象的建立者的權限，及授予新建的使用者或數據庫的權限。
3.顯示授予的權限:此為由任何具有 WITHGRANTOPTION 特權的使用者所授予的權限。顯示授予(通過命令顯示地以陳述方式授予)的權限可使用 Teradata 的 SQL GRANT 命令來授予。
同時使用數據庫存取日記進行安全管理：
通過存取日志記錄使用者在數據庫中的所有活動，如果使用者嘗試存取某一數據庫對象，且該對象已包含在目前的日志定義中，則系統會記錄其使用者識別碼、對象名稱及此一存取動作是否被相應的存取權限所允許。所使用的 SQL 語句也可以選擇性的被記錄下來。
設計思路
前后端完全分離，僅通過http接口進行交互，實現各端完全透明，代碼的維護升級互不干擾，使用mysql + springboot + html + Android + vue進行開發。
part.04 本次作業隊員貢獻度
-
為了調動成員積極性，增加團隊成員之間的配合以及加強在今后的合理分工，本團隊從本次開始，引入對成員分工的工作進行加權，用文檔記錄，最后按總權分配貢獻比。
-
團隊分工文檔下載：<團隊分工文檔>
| 學號 | 工作內容 | 貢獻度 |
|---|---|---|
| 221701412 | 系統設計和數據庫設計答辯 PPT（1）、進行答辯（1）、類圖設計（1）、參與各部分修改與建議（0.5） | 17.5% |
| 221701414 | 編寫完成博客（2)、參與各部分修改與建議（0.5） | 12.5% |
| 221701417 | 答辯打分（1）、系統設計和數據庫設計評審表（1）、記錄 Q&A 記錄（0.5）、系統設計和數據庫設計答辯 PPT（1） | 17.5% |
| 221701418 | 系統設計說明書（2） | 10% |
| 221701420 | 泳道圖（1）、數據流圖（1） | 10% |
| 221701429 | 數據庫設計說明書（2） | 10% |
| 221701431 | 數據庫設計說明書（2） | 10% |
| 221701439 | 系統設計說明書（2）、記錄 Q&A 記錄（0.5） | 12.5% |
Part.05 答辯匯總
選題答辯
-
1.平台是否支持校友租賃物品？
- A：不支持校友，已步入社會的校友加入，會增加很多隱患，使用 orc 讀取校園的學生卡和教師卡，僅支持在校師生使用，可以寫一個 Timer 定時器，一年更新一次數據庫的用戶，對於正則匹配的學號往后移 3 年已過期的用戶將限制其功能的使用。
-
2.這些平台重要的是“維護者”，這一點如何保證？
- A：在本團隊成員在校期間，我們是維護者，當我們離校后現在的打算是傳給學弟學妹們繼續維護，一代一代的維護。后續我們會考慮產品的商業盈利問題，有了收益，更有利於維護和發展。
-
3.往屆做類似產品的很多，但是限於時間和技術，都無法開發出預期的所有功能，你們有做技術可行性分析嗎？
- A：團隊成員項目經驗較同級一些同學相對來說要豐富，有在 ppt 中展示，且這次產品考慮的主要的三個模塊，在以前團隊的成員都有寫過類似，這次的開發主要是建立在復用以前代碼基礎拓展新的功能且優化，有較大可行性。目前團隊已經開始着手准備這一項目。
-
4、新的思考
- A：作為旗山的驕傲，我們是一個團隊，在開發中需要始終保持一致的目標、明確的分工。我們的目標是開發出一個可維護、可迭代、可投入現實中使用的產品。為此，我們開始着手准備相關的知識。
原型答辯
-
1.租賃涉及到費用，如何交易？
- A：我們的校園介子空間平台是一個綜合性的校園平台，目前我們平台的定位是信息共享，是在對競品（福大小黑板等一眾公眾號）進行對比分析得出的信息共享平台，區別於咸魚等購物平台，買賣雙方在我們的平台獲取相關信息后，交易由雙方自己線下協商完成。
-
2.如何處理交易爭端？(租賃的物品被損壞並且租賃方不認為是自己的問題)
- A：我們的校園介子空間平台是一個綜合性的校園平台，目前我們平台的定位是信息共享，是在對競品（福大小黑板等一眾公眾號）進行對比分析得出的信息共享平台，區別於咸魚等購物平台，買賣雙方在我們的平台獲取相關信息后，交易由雙方自己線下協商完成，如果出現租賃的物品被損壞並且租賃方不認為是自己的問題，本平台可為雙方的交易爭端提供平台的聊天內容作為證據。
-
3.對於涉密等敏感話題，打算采用什么算法？
- A：對於涉及涉密等敏感話題，主要通過兩個途徑，一個是管理員在后台的初步審核，一個是在答辯老師提醒增加的舉報功能，在前台界面當一條疑似涉密等敏感話題的發布舉報次數達到一定次數（如 100 次）時，邏輯處理模塊會將此條發布在后台報警，以進行人工核實。
-
4.是否涉及押金？
- A：我們的校園介子空間平台是一個綜合性的校園平台，目前我們平台的定位是信息共享，是在對競品（福大小黑板等一眾公眾號）進行對比分析得出的信息共享平台，區別於咸魚等購物平台，買賣雙方在我們的平台獲取相關信息后，交易由雙方自己線下協商完成，所以本平台並不涉及押金。
-
5、平台涉及的交易如何完成？
- A：我們的校園介子空間平台是一個綜合性的校園平台，目前我們平台的定位是信息共享，是在對競品（福大小黑板等一眾公眾號）進行對比分析得出的信息共享平台，區別於咸魚等購物平台，買賣雙方在我們的平台獲取相關信息后，交易由雙方自己線下協商完成。
-
6、建議平台能提供舉報這一功能。
- A：在答辯老師提醒增加的舉報功能，在前台界面當一條疑似涉密等敏感話題的發布舉報次數達到一定次數（如 100 次）時，邏輯處理模塊會將此條發布在后台報警，以進行人工核實。
需求分析答辯
-
1、單獨設立 失物招領 和 尋物啟事 兩個類，是否存在重復，這樣的關系是否准確。
- A：不重復，因為這兩個東西容易混淆，考慮到易於理解性，並且兩個類含有的屬性並不完全相同，我們決定將這兩個類分開。
-
2、在發布任務功能，一個任務要體現發布任務者和領取任務者嗎？
- A：我們的目標是提供一個發布信息、獲取信息的平台，原則上只對涉及違規違法的敏感信息進行處理，不會干涉任務的處理進度。比如：某個用戶在朋友圈發布了一條任務信息，另外一個用戶獲取任務信息后想要領取任務，對於領取任務這些具體的細節交由雙方通過發布的信息中留下的聯系方式，自行協商。
-
3、類似的物品租賃類的屬性是否不夠？
- A：我們已經在任務詳情中對屬性進行了補充。
-
4、如果不記錄誰完成的話對后續信譽記錄什么的會有影響嗎？
- A：針對這個問題，我們增加了舉報功能，對於破壞信譽的行為，用戶可以在舉報功能中，上傳相關的信息，經后台審核后，對被舉報的賬號進行封號等操作，對於涉及違法的問題，會提供相關信息，協助舉報人報警。
-
5、敏感詞建議單獨放一張表。
- A：感謝老師提出建議，我們在系統設計的時候做出了相應的修改。
Part.06 github倉庫地址以及下載鏈接
-
Github 團隊倉庫鏈接：<點擊進入>
-
旗山的驕傲_系統設計說明書.pdf：<點擊下載>
-
旗山的驕傲_數據庫設計說明書.pdf:<點擊下載>
-
旗山的驕傲_系統設計和數據庫設計答辯 PPT.pdf: <點擊下載>
Part.07 本項目目前的全部附件
如果您覺得一個一個下麻煩的話，可以在這里下載本項目目前的全部附件
-
本項目目前的全部附件下載（百度雲鏈接：提取碼（yjuf)）：<本項目目前的全部附件>
Part.08 本次答辯的評審表
-
項目系統設計與數據庫設計評審表：<點擊進入>
Part.09 本次答辯Q&A回答以及對答辯的補充
-
汪老師：
-
1、此處使用繼承，請解釋一下，能否考慮用組合？
- A:此處使用繼承是因為在分析階段的類圖在提取需求時，這三個實體類均有公共的屬性，於是提取了一個發布的總類類作為父類型，然后繼承下去三個子類型再實現對應不同屬性，所以此處使用繼承，組合關系中的整體直接掌握部件的生滅，聚合關系中的整體並不具有生滅部件的權力。一旦組合中的整體不存在時，其組合部件也不能單獨存在，必須同時消滅。另外，外界也不能直接與部件溝通，必須通過整體代為傳達消息。然而在此系統中子類型仍與其他的部分有直接的關聯，所以本小組討論后還是認為使用繼承更為恰當。
-
2、虛線表示什么含義？
- A:ER圖的虛線應該是表示week entity，即需要借助外鍵和標有虛線的partial key來確定的實體，但是在之前的這個ER圖的該場景這樣使用並不恰當，現已在博客上傳了修改后的版本。
-
傅老師：
-
1、舉報表沒有涉及user_id?
- A:舉報表沒有涉及user_id，在之前是打算設計為由舉報表的table_id在對應的發布類的表查詢對應的user_id，即進行一個多表查詢，在答辯后小組有對此設計進行討論，認為在后續的開發階段應該在舉報表加入user_id，這樣的設計明顯更為合理。
-
2、實體之間的關系沒有標注
- A：實體之間的關系現已進行標注，現已在博客上傳了修改后的版本。
-
樂助教：
-
1、總的來說設計的不錯；評審表布局可以稍微優化一下；ER圖繪制的不太規范
- A：評審表布局現已進行了一定的調整，er圖確實繪制的不規范現已在博客上傳了修改后的版本。這次我們小組拿出的成果確實有一些不盡人意的地方，現已在博客更新了第九部分對答辯q&a進行回答以及對一些我們組認為在答辯中不足的地方進行了一定補充，我們在下次將吸取問題教訓在繼續發揮我們的長處的同時改正問題，我們會加油的！！！
-
對於答辯的一些補充：在答辯階段並沒有給出具體的接口設計，本着得盡量完整每一次的設計，這樣才能將這樣的一個完整的項目環環相扣的設計下去，在此博客里我們小組還是重新給出了接口設計，亡羊補牢為時應該不晚！！
