前言
随着社会的发展，人民消费需求的旺盛，各路网络贷款平台开始像潮水一样涌出，这给了网络贷款这一新型贷款方式极大的发展空间，本系统致力于构建一个好的网络贷款平台，能够方便用户的贷款需求。因为系统的开发工作才进行了一半，因此，这里主要是根据自己的理解来进行下面的分析。
需求分析
该系统分为前台系统和后台管理系统，前台即用户所见的平台，后台即后台的管理员进行审核等操作所用的平台。
其中管理员用户区分了业务员，也就是给用户办业务的人员和超级管理员，比如公司的上层管理，当然，还有一些较为复杂的功能，随着系统的逐步开发，会逐渐深入，这里只是一个引子，学习建模的方法和思路。
用户需求
- 注册
- 登录
- 找回密码
- 实名认证
- 提交借款
业务员需求
这里如上的注册、登录、找回密码等基础功能默认省略。
- 添加借款
- 查看审核中列表
- 查看审核通过列表
- 查看审核不通过列表
- 查看待提交列表
超级管理员需求
这里如上的注册、登录、找回密码等基础功能默认省略。
- 区域设置
- 用户管理
- 角色管理
- 操作日志
用例建模
因为用户的用例主要是界面的一些操作，较为简单，这里的用例建模以业务员和超级管理员为例。
业务员用例
超级管理员用例
业务类建模
因为系统开发得还不够深入，这里只能给出目前可能会用到的一些业务类的建模。
这里采用了基于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/