前言
隨着社會的發展，人民消費需求的旺盛，各路網絡貸款平台開始像潮水一樣涌出，這給了網絡貸款這一新型貸款方式極大的發展空間，本系統致力於構建一個好的網絡貸款平台，能夠方便用戶的貸款需求。因為系統的開發工作才進行了一半，因此，這里主要是根據自己的理解來進行下面的分析。
需求分析
該系統分為前台系統和后台管理系統，前台即用戶所見的平台，后台即后台的管理員進行審核等操作所用的平台。
其中管理員用戶區分了業務員，也就是給用戶辦業務的人員和超級管理員，比如公司的上層管理，當然，還有一些較為復雜的功能，隨着系統的逐步開發，會逐漸深入，這里只是一個引子，學習建模的方法和思路。
用戶需求
- 注冊
- 登錄
- 找回密碼
- 實名認證
- 提交借款
業務員需求
這里如上的注冊、登錄、找回密碼等基礎功能默認省略。
- 添加借款
- 查看審核中列表
- 查看審核通過列表
- 查看審核不通過列表
- 查看待提交列表
超級管理員需求
這里如上的注冊、登錄、找回密碼等基礎功能默認省略。
- 區域設置
- 用戶管理
- 角色管理
- 操作日志
用例建模
因為用戶的用例主要是界面的一些操作，較為簡單，這里的用例建模以業務員和超級管理員為例。
業務員用例
超級管理員用例
業務類建模
因為系統開發得還不夠深入，這里只能給出目前可能會用到的一些業務類的建模。
這里采用了基於MVC的Java Web項目開發架構，因為MVC事實上只是一種設計思想，這種設計思想的目的是為了解耦，因此本項目在實際應用時並非完全只划分了Model-View-Controller三層，我們在這之上略微有些許延伸，事實上，很多實際的Java Web項目的開發都是這樣做的。本項目的業務邏輯類主要分為以下三大塊：
- Dao層：數據庫訪問層，對應數據庫表做增刪改查。
- Service層：對Dao層的增刪改查整合，通過這一層來進行解耦，使得Dao層內的變化不會直接影響到Controller層。
- Controller層：定義路由訪問，對service層整合。
下面是本項目可能會用到的主要借款有關的業務類，能想到的方法都加進去了。
關系數據模型建模
概念數據模型
概念數據模型（Conceptual Data Model）：簡稱概念模型 ，主要用來描述世界的概念化結構，它使數據庫的設計人員在設計的初始階段，擺脫計算機系統及DBMS的具體技術問題，集中精力分析數據以及數據之間的聯系等，與具體的數據庫管理系統（Database Management System，簡稱DBMS）無關。概念數據模型必須換成邏輯數據模型，才能在DBMS中實現。
“E-R圖”是一種介紹概念數據模型的合理方式，這里主要采用它來介紹，下面是本項目前期根據網上了解的相關情況和組員的想法繪制的“E-R圖”：
物理數據模型
物理數據模型（Physical Data Model）:簡稱物理模型 ，是面向計算機物理表示的模型，描述了數據在儲存介質上的組織結構，它不但與具體的DBMS有關，而且還與操作系統和硬件有關。每一種邏輯數據模型在實現時都有起對應的物理數據模型。DBMS為了保證其獨立性與可移植性，大部分物理數據模型的實現工作又系統自動完成，而設計者只設計索引、聚集等特殊結構。
這里直接采用數據表來介紹相關的物理數據模型。下面給出本項目所用到的主要數據庫表：
用戶表（通過用戶組和權限來區分三大用戶）：
| 字段 | 說明 |
|---|---|
| id | 用戶id |
| user | 用戶名 |
| user_group | 用戶組名 |
| area | 城市碼表 |
| role | 角色 |
| permission | 權限 |
| loan_product_info | 貸款產品信息 |
| loan_product_type | 貸款產品類型 |
| user_loan_basic | 用戶貸款基本信息 |
| user_loan_detail | 用戶貸款明細 |
| user_loan_doc | 用戶貸款資料 |
| user_loan_cost | 用戶貸款費用 |
| op_log | 操作日志 |
貸款產品表：
| 字段 | 說明 |
|---|---|
| id | 貸款產品id |
| product_name | 產品名稱 |
| loan_type | 貸款類型 |
| is_effective | 是否有效 |
| effective_date | 生效日期 |
| ineffective_date | 失效日期 |
| create_time | 記錄創建時間 |
| update_time | 記錄更新時間 |
| create_by | 記錄創建人id |
| update_by | 記錄更新人id |
用戶借款信息表：
| 字段 | 說明 |
|---|---|
| id | 貸款產品id |
| product_name | 產品名稱 |
| apply_user_id | 申請用戶id |
| apply_user_name | 申請用戶名 |
| sales_man_id | 業務員id |
| sales_man_name | 業務員名 |
| apply_time | 申請時間 |
| audit_user_id | 審核人id |
| audit_user_name | 審核人姓名 |
| audit_time | 審核時間 |
| pay_time | 打款時間 |
| create_time | 記錄創建時間 |
| update_time | 記錄更新時間 |
概念原型與工作過程
概念原型
概念是人對能代表某種事物或發展過程的特點及意義所形成的思維結論。
概念原型是一種虛擬的、理想化的軟件產品形式。
工作過程
這里簡單地模擬一下三大用戶的工作過程，我們的系統在設計完成后可以模擬以下工作過程進行測試。
普通用戶：
- 注冊賬戶 => 登錄 => 提交借款
- 登錄 => 注冊賬戶 => 登錄 => 提交借款
- 登錄 => 忘記密碼 => 修改密碼 => 登錄 => 提交借款
業務員：
- 添加借款 => 異常處理 => 上傳失敗 => 添加失敗
- 添加借款 => 異常處理 => 資料上傳 => 異常處理 => 上傳失敗 => 添加失敗
- 添加借款 => 資料上傳 => 上傳成功 => 添加成功
- 添加借款 => 異常處理 => 資料上傳 => 上傳成功 => 添加成功
- 添加借款 => 異常處理 => 資料上傳 => 異常處理 => 上傳成功 => 添加成功
超級管理員：
- 用戶管理 => 添加用戶信息
- 用戶管理 => 更新用戶信息
- 用戶管理 => 刪除用戶信息
- 用戶管理 => 導出用戶列表
- 角色管理 => 新增角色
- 角色管理 => 調整角色
- 角色管理 => 刪除角色
- 區域設置 => 業務員信息設置
- 區域設置 => 系統信息設置
- 操作日志 => 導出操作日志
總結
本文主要采用老師上課所講方法對自己所做的系統進行需求分析和建模，因為項目才開始一點點，還有很多功能沒有想到，很不細致。當然，這次博客的目的還是達到了，就是學習需求分析和系統建模的方法。
參考資料
- https://gitee.com/mengning997/se/tree/master/ppt
- 《三層架構：表示層-業務邏輯層-數據訪問層》
https://blog.csdn.net/m0_37033566/article/details/53787055 - 《如何設計Service層》
https://blog.csdn.net/qq_34339493/article/details/86479991 - 《Service層和Controller層的開發》
https://www.jianshu.com/p/553980575709 - 《數據庫建模三步驟：概念模型->邏輯模型->物理模型》
https://blog.csdn.net/caodongfang126/article/details/90665339 - 《UML教程》
https://www.w3cschool.cn/uml_tutorial/