企业资源计划系统（ERPS）用例文档
0. 文档修改历史
| 更新者 | 更新日期 | 更新内容 | 版本号 |
|---|---|---|---|
| 徐晨 | 2022.7.2 | 用例总经理部分v0.1 | 1.0 |
| 徐晨 | 2022.7.6 | 用例财务人员部分v0.1 | 1.1 |
| 何沛阳 | 2022.7.9 | 用例财务人员部分v0.2 | 1.2 |
| 徐晨 | 2022.7.9 | 用例修改 | 1.3 |
1. 引言
1.1 目的
1.2 参考文献
- 软件工程与计算（卷二）：软件开发的技术基础
2. 用例列表
| 参与者 | 用例 | | —- | —- | | 财务人员 | 1.账户管理
2.制定收款单
3.制定付款单
4.制定工资单
5.制定现金消费单
10.查看表单（具体是经营历程表、销售明细表、经营情况表） | | 人力资源人员 | 6.员工管理
7.员工打卡
8.薪酬规则制定 | | 总经理 | 9.制定促销策略
10.查看表单（具体是经营历程表、销售明细表、经营情况表）
11.审批财务类单据 |
3. 详细用例描述
用例1 账户管理
| ID | 1 |
|---|---|
| 名称 | 账户管理 |
| 创建者 | 徐晨 |
| 创建日期 | 2022.6.30 |
| 最后一次更新者 | 徐晨 |
| 最后更新日期 | 2022.7.8 |
| 参与者 | 财务人员 |
| 触发条件 | 财务人员需要进行银行账户的增加、删除、查询 |
| 前置条件 | 财务人员已经登录（若要进行查询操作，则必须通过最高权限认证） |
| 后置条件 | 存储操作记录； 更新账户记录； |
| 优先级 | 高 |
| 正常流程 | 1. 财务人员选择新建账户，输入账户名称和账户金额并创建； 1. 系统显示创建成功，存储账户名称与金额； 1. 财务人员输入账户名称并删除账户； 1. 系统显示删除成功，删除数据库中对应账户； 1. 最高权限财务人员输入账户名称并查询； 1. 系统显示查询到的账户名称及账户余额； |
| 扩展流程 | 1a. 创建账户与已有账户同名； 1b. 系统显示存在同名账户，拒绝新增账户； 2a. 删除账户不在数据库中； 2b. 系统显示指定账户不存在，拒绝删除账户； 3a. 查询账户不在数据库中； 3b. 系统显示未查询到结果； |
| 特殊需求 | 无 |
用例2 制定收款单
| ID | 2 |
|---|---|
| 名称 | 制定收款单 |
| 创建者 | 徐晨 |
| 创建日期 | 2022.6.30 |
| 最后一次更新者 | 徐晨 |
| 最后更新日期 | 2022.7.9 |
| 参与者 | 财务人员 |
| 触发条件 | 财务人员需要制定收款单 |
| 前置条件 | 财务人员已经登录 |
| 后置条件 | 一条收款单进入待审批状态并且记录被存储 |
| 优先级 | 高 |
| 正常流程 | 1. 财务人员选择新建收款单 1. 系统显示收款单创建页面 1. 财务人员选择客户、输入转账列表（银行账户、转账金额、备注）、总额汇总，并提交 1. 系统显示提交成功 |
| 扩展流程 | 无 |
| 特殊需求 | 无 |
用例3 制定付款单
| ID | 3 |
|---|---|
| 名称 | 制定付款单 |
| 创建者 | 徐晨 |
| 创建日期 | 2022.7.5 |
| 最后一次更新者 | 徐晨 |
| 最后更新日期 | 2022.7.8 |
| 参与者 | 财务人员 |
| 触发条件 | 财务人员需要制定付款单 |
| 前置条件 | 财务人员已经登录 |
| 后置条件 | 一条付款单进入待审批状态并且记录被存储 |
| 优先级 | 高 |
| 正常流程 | 1. 财务人员选择新建付款单 1. 系统显示付款单单创建页面 1. 财务人员选择银行账户、输入条目清单（条目名、金额、备注）、总额，并提交 1. 系统显示提交成功 |
| 扩展流程 | 无 |
| 特殊需求 | 无 |
用例4 制定工资单
| ID | 4 |
|---|---|
| 名称 | 制定工资单 |
| 创建者 | 徐晨 |
| 创建日期 | 2022.7.8 |
| 最后一次更新者 | 徐晨 |
| 最后更新日期 | 2022.7.8 |
| 参与者 | 财务人员 |
| 触发条件 | 财务人员需要制定工资单 |
| 前置条件 | 财务人员已经登录 |
| 后置条件 | 一条工资单进入待审批状态并且记录被存储 |
| 优先级 | 高 |
| 正常流程 | 1. 财务人员选择新建工资单 1. 系统显示工资单创建页面 1. 财务人员输入员工编号、姓名、银行账户信息、应发工资、扣除税款、实发金额，并提交 1. 系统显示提交成功 |
| 扩展流程 | 无 |
| 特殊需求 | 无 |
用例5 制定现金消费单
| ID | 5 |
|---|---|
| 名称 | 制定现金消费单 |
| 创建者 | 徐晨 |
| 创建日期 | 2022.7.8 |
| 最后一次更新者 | 何沛阳 |
| 最后更新日期 | 2022.7.9 |
| 参与者 | 财务人员 |
| 触发条件 | 财务人员需要制定现金消费单 |
| 前置条件 | 财务人员已经登录 |
| 后置条件 | 1. 一条现金消费单被存储 1. 相应的银行卡属性被更新 |
| 优先级 | 高 |
| 正常流程 | 1. 财务人员选择新建现金费用单，并输入相应的信息 1. 系统显示创建成功 1. 系统自动完成存储现金费用单记录和更新银行卡信息 |
| 扩展流程 | 无 |
| 特殊需求 | 无 |
用例6 员工管理
| ID | 6 |
|---|---|
| 名称 | 员工管理 |
| 创建者 | 徐晨 |
| 创建日期 | 2022.7.1 |
| 最后一次更新者 | 徐晨 |
| 最后更新日期 | 2022.7.8 |
| 参与者 | 人力资源人员 |
| 触发条件 | 人力资源人员需要进行员工管理 |
| 前置条件 | 人力资源人员已经登录 |
| 后置条件 | 员工信息更改 |
| 优先级 | 高 |
| 正常流程 | 1. 人力资源人员选择新增或改变员工信息 1. 系统显示员工管理界面 1. 人力资源人员输入姓名、手机号、工资卡账户，选择性别、出生日期、工作岗位、薪资计算方式、薪资发放方式并确认新增或改变（改变时相应位置默认是原始值） 1. 系统显示提交成功 |
| 扩展流程 | 无 |
| 特殊需求 | 无 |
用例7 员工打卡
| ID | 7 |
|---|---|
| 名称 | 员工打卡 |
| 创建者 | 徐晨 |
| 创建日期 | 2022.6.30 |
| 最后一次更新者 | 徐晨 |
| 最后更新日期 | 2022.7.8 |
| 参与者 | 除总经理外的所有员工 |
| 触发条件 | 除总经理外的任意员工进行登录操作 |
| 前置条件 | 员工通过身份认证 |
| 后置条件 | 打卡信息存储 |
| 优先级 | 低 |
| 正常流程 | 员工登录； 系统显示登陆后页面，自动保存打卡信息； |
| 扩展流程 | 无 |
| 特殊需求 | 无 |
用例8 薪酬规则制定
| ID | 8 |
|---|---|
| 名称 | 薪酬规则制定 |
| 创建者 | 徐晨 |
| 创建日期 | 2022.7.2 |
| 最后一次更新者 | 徐晨 |
| 最后更新日期 | 2022.7.9 |
| 参与者 | 人力资源人员（年终奖由总经理制定） |
| 触发条件 | 人力资源人员需要进行人员的薪酬规则制定 |
| 前置条件 | 人力资源人员已经登录 |
| 后置条件 | 薪酬规则改变 |
| 优先级 | 高 |
| 正常流程 | 1. 人力资源人员选择需要制定或改变薪酬规则的岗位 1. 系统显示薪酬规则制定页面 1. 人力资源人员输入岗位对应的基本工资、岗位工资，选择薪资计算方式、薪资发放方式、扣税信息并确认 1. 系统显示制定薪酬规则成功 |
| 扩展流程 | 无 |
| 特殊需求 | 无 |
用例9 制定促销策略
| ID | 9 |
|---|---|
| 名称 | 制定促销策略 |
| 创建者 | 徐晨 |
| 创建日期 | 2022.7.8 |
| 最后一次更新者 | 徐晨 |
| 最后更新日期 | 2022.7.9 |
| 参与者 | 总经理 |
| 触发条件 | 总经理需要制定促销策略 |
| 前置条件 | 总经理已经登录 |
| 后置条件 | 促销策略改变 |
| 优先级 | 高 |
| 正常流程 | 1. 总经理选择促销策略（提供两种特殊策略，策略一是根据客户等级给予不同的折扣；策略二是根据商品总价给予代金券和赠品；两者都不选则为默认策略，直接计算折扣和代金券） 2. 系统显示策略制定界面； 3a. 策略一中，总经理编辑不同等级对应的折扣力度 3b. 策略二中，总经理设置优惠总价档位、代金券面值、赠品列表 4. 系统建立库存赠送单，显示制定促销策略成功，发送消息给库存管理员发放赠品 |
| 扩展流程 | 无 |
| 特殊需求 | 无 |
用例10 查看表单（具体是经营历程表、销售明细表、经营情况表）
| ID | 10 |
|---|---|
| 名称 | 查看表单 |
| 创建者 | 徐晨 |
| 创建日期 | 2022.7.8 |
| 最后一次更新者 | 徐晨 |
| 最后更新日期 | 2022.7.9 |
| 参与者 | 总经理、财务人员（总经理无法使用红冲功能） |
| 触发条件 | 总经理或财务人员需要查看经营历程表 |
| 前置条件 | 总经理或财务人员已经登录 |
| 后置条件 | 系统显示所选表单 |
| 优先级 | 高 |
| 正常流程 | 1. 用户选择要查看的单据类型（销售类、库存类、财务类） 1. 用户根据不同的单据类型，输入相应的筛选条件 1. 系统返回查询结果 1. 用户选中某条单据，进行红冲操作 1. 系统存储红冲产生的单据记录 |
| 扩展流程 | 3a. 系统未查询到所用筛选条件，显示未查询到结果 |
| 特殊需求 | 无 |
用例11 审批财务类单据
| ID | 11 |
|---|---|
| 名称 | 审批财务类单据 |
| 创建者 | 何沛阳 |
| 创建日期 | 2022.7.9 |
| 最后一次更新者 | 徐晨 |
| 最后更新日期 | 2022.7.9 |
| 参与者 | 总经理 |
| 触发条件 | 总经理需要审批财务类单据 |
| 前置条件 | 总经理已经登录 |
| 后置条件 | 1. 某条财务类单据的单据状态被改变 1. 对应的账户属性、客户应收应付被更改 |
| 优先级 | 高 |
| 正常流程 | 1. 总经理选择需要审批的单据类型 1. 系统显示出选中类型的所有待审批单据 1. 总经理进行单据审批，审批结果为“审批完成”“审批失败”其一 1. 系统提示审批成功，更改相应单据的状态；若单据审批通过，则系统要自动修改相关银行账户、客户应付应收的属性 |
| 扩展流程 | 4a. 单据审批通过后，修改后的客户应收应付款额小于0 4b. 系统将单据的状态改为“审批失败”，并提示用户出错原因 |
| 特殊需求 | 无 |
企业资源计划系统（ERPS）软件需求规格说明文档
0. 文档修改历史
| 修改人员 | 日期 | 修改内容 | 版本号 |
|---|---|---|---|
| 徐晨 | 2022.7.2 | 完成引言部分与总体描述部分 | 1.0 |
| 徐晨 | 2022.7.3 | 完成非功能需求部分 | 1.1 |
| 徐晨 | 2022.7.5 | 修改总体描述部分的业务需求、用户特征和约束 | 1.2 |
| 徐晨 | 2022.7.6 | 完成功能需求部分 | 1.3 |
| 徐晨 | 2022.7.6 | 增加功能需求3.2.5-3.2.7 | 1.4 |
| 徐晨 | 2022.7.7 | 更改功能需求3.2.6 | 1.5 |
1. 引言
1.1 目的
本文档描述了ERPS在lab7中的功能需求和非功能需求。本组的ERPS实现与验证工作都以此文档为依据。
1.2 范围
ERPS是为*民营企业开发的企业资源计划系统，开发的目标是使公司减少积压的库存，增加销售额，提高财务人员和人力资源人员工作效率，为经理的决策做支持
1.3 参考文献
- 企业资源计划系统（ERPS）用例文档
- 软件工程与计算（卷二）：软件开发的技术基础
2. 总体描述
2.1 系统前景
2.1.1 背景与机遇
*民营企业专业从事灯具开关行业，是某著名开关品牌的南京地区总代理，主要在南京负责品牌的推广及项目的落地销售、分销的批发等工作，服务对象包括项目业主、施工单位、分销商、设计院、终端用户等。
现公司规模扩大，企业业务量、办公场所、员工数都发生增长，为适应新的环境，提高工作效率和用户满意度， 该公司聘南鲸软件科技公司开发一套ERP 系统。该系统主要包括库存管理、销售管理、财务管理、人事管理和企业经营管理。2.1.2 业务需求
BR1：在系统上线运行六个月后，财务人员和人力资源人员工作效率提高，如：财务人员处理相同数量单据的时间减少50%；人力资源人员处理相同管理人员事务的时间减少50%
BR2：在系统上线运行六个月后，经理决策效率提高，如：总经理审批相同单据的时间减少50%2.2 系统功能
SF1：制定单据（收款单、付款单、工资单）
SF2：查看表单（销售明细表、经营历程表、经营情况表）
SF3：制定促销策略
SF4：账户管理
SF4：帮助人力资源人员处理薪酬规则制定、员工管理的任务
SF6：实现员工打卡，提高员工积极性
SF7：审批财务类单据2.3 用户特征
| 人力资源人员 | 1到2名。办公信息化系统较强。对新系统态度持积极态度。不希望增加现有工作量。 | | —- | —- | | 总经理 | 2名。能够熟练使用办公信息化系统。对新系统态度持积极态度。 | | 财务人员 | 1到2名。办公信息化系统较强。持积极态度。不希望增加现有工作量。 |
2.4 约束
con1. 系统将运行在Windows10及以上版本的操作系统上
con2. 系统使用Web界面
con3. 项目使用持续集成进行开发
con4. 在开发中，开发者要提交软件需求规格说明文档、设计描述文档、测试报告
3. 详细需求描述
3.1 对外接口需求
3.1.1 用户界面
3.1.2 通信接口
3.2 功能需求
3.2.1 制定单据
3.2.1.1 特性描述
在选择制定的单据后，经过验证的财务人员开始制定对应单据
优先级=高
3.2.1.2 刺激/响应序列
刺激：财务人员选择需要制作的单据类型
响应：系统显示所选单据的制定页面
刺激：财务人员输入创建信息
响应：系统显示创建成功，将单据发送给总经理进行审批，单据为待审批状态
3.2.2 查看表单
3.2.2.1 特性描述
经过验证的总经理或财务人员选择要查看的单据类型，系统显示所选类型的表单页面
优先级=高
3.2.2.2 刺激/响应序列
刺激：选择需要查看的单据类型
响应：系统显示所选单据类型的页面
刺激：选择需要查看的单据
响应：系统显示所选单据的页面
3.2.3 制定促销策略
3.2.3.1 特性描述
经过认证的总经理选择促销策略类型，选择/输入参数，制定相应促销策略
优先级=高
3.2.3.2 刺激/响应序列
刺激：总经理选择促销策略
响应：系统显示所选择的策略制定界面
刺激：总经理编辑不同等级对应的折扣力度（策略一）；总经理设置优惠总价档位、代金券面值、赠品列表（策略二）
响应：系统建立库存赠送单，显示制定促销策略成功，发送消息给库存管理员发放赠品
3.2.4 账户管理
3.2.4.1 特性描述
财务人员在经过验证后，进行银行账户的增加、删除、查询（查询只有最高权限能够使用）
优先级=高
3.2.4.2 刺激/响应序列
刺激：财务人员选择新建账户
响应：系统显示新建账户页面
刺激：财务人员输入账户名称、金额并确定
响应：系统显示新建账户成功，存储账户名称与金额
刺激：创建账户与已有帐户同名
响应：系统显示存在同名账户，拒绝新增账户
刺激：财务人员选择删除账户
响应：系统显示删除账户页面
刺激：财务人员输入所要删除的账户名称并确定
响应：系统显示删除成功，删除对应账户
刺激：删除账户不在数据库中
响应：系统显示指定账户不存在，拒绝删除账户
刺激：有最高权限的财务人员选择查询账户
响应：系统显示查询账户页面
刺激：没有最高权限的财务人员选择查询账户
响应：系统显示无权限查询账户
刺激：输入账户名称并查询
响应：系统显示查询到的账户名称及账户余额
刺激：输入账户不在数据库中
响应：系统显示未查询到结果
3.2.5 帮助人力资源人员处理薪酬规则制定、员工管理的任务
3.2.5.1 特性描述
人力资源人员设置岗位对应的基本工资、岗位工资、岗位级别、薪资计算方式、薪资发放方式、扣税信息等制度信息，管理每个员工的信息（姓名、性别、出生日期、手机号、岗位）、工资卡账户。
3.2.5.2 刺激/响应序列
刺激：人力资源人员选择需要制定或改变薪酬的岗位
响应：系统显示薪酬规则制定页面
刺激：人力资源人员输入岗位对应的基本工资、岗位工资，选择薪资计算方式、薪资发放方式、扣税信息并确认
响应：系统显示制定薪酬规则成功
刺激：人力资源人员选择新增或改变员工信息
响应：系统显示员工管理界面
刺激：人力资源人员输入姓名、手机号、工资卡账户，选择性别、出生日期、工作岗位、薪资计算方式、薪资发放方式并确认新增或改变（改变时相应位置默认是原始值）
响应：系统显示提交成功
3.2.6实现员工打卡，提高员工积极性
3.2.6.1 特性描述
除总经理外的所有员工进行打卡，人力资源人员管理打卡数据
优先级=低
3.2.6.2 刺激/响应序列
刺激：非总经理员工登录
响应：系统存储该员工的打卡记录
刺激：人力资源人员选择查看打卡数据
响应：系统显示员工打卡数据页面
3.2.7 审批财务类单据
3.2.7.1 特性描述
财务人员提交财务类单据创建申请后，总经理处收到审批请求，总经理进行审批
优先级=高
3.2.7.2 刺激/响应序列
刺激：总经理选择审批某一财务类单据
响应：系统显示该类单据对应的审批页面
刺激：总经理选择审批通过
响应：系统显示审批成功，更改响应单据状态，相关账户、客户的应收属性自动修改
刺激：总经理选择审批不通过
响应：系统显示审批成功，更改响应单据状态，单据创建者收到审批未通过的通知
3.3 非功能需求
3.3.1 安全性
Safety1：系统应该只允许经过验证和授权的用户访问
Safety2：系统应该按照用户身份验证用户的访问权限：身份授权参见功能需求3.2
Safety3：系统中有一个默认的管理员账户，该账户只允许管理员用户修改口令（本系统中管理员用户名为sky）
3.3.2 可维护性
Modifiability1：在系统的商品标识数据格式发生变化时，系统要能够在1人1天内完成。
Modifiability2：如果系统要增加新的促销策略，要能够在0.1个人月内完成。
3.3.3 易用性
3.3.4 可靠性
Reliability1：在客户端与服务器通信时，如果网络故障，系统不能出现故障。
Reliability6.1：客户端检测到故障应尝试重新连接网络3次
Reliability6.1.1：重新连接后，客户端应该继续之前的工作
Reliability6.2：客户端检测到故障应自动保存当前状态，以便恢复
Reliability2：若浏览器不兼容，显示解决方案
3.4 数据需求
3.4.1 数据定义
3.4.2 默认数据
Default1：商品的数量默认为0
Default2：商品出库原因默认为到期报废
Default3：时间默认为系统时间
Default4：操作人员工号默认为当前登录用户
3.4.3 数据格式要求
Format1：商品入库的原因必须为销售退货、进货和其他
Fromat2：商品出库的原因必须为到期报废、个别残次品、批次质量缺陷、销售、进货退货和其他
Format3：价格和费用的格式必须是大于等于0 、精确到小数点后2位的浮点数，单位为元。
Format4：日期的格式必须是yyyy-mm-dd
Format5：数量的格式必须是正整数
3.5 其他需求
Install1：在安装系统时，要初始化用户、商品库存等重要数据。
Install2：系统投入使用时，需要对用户进行1天的培训。
企业资源计划系统（ERPS）体系结构描述文档
0. 文档修改历史
| 修改人员 | 日期 | 修改原因 | 版本号 |
|---|---|---|---|
| 徐晨 | 2022.7.2 | 完成目录引言参考资料产品概述模块视图 | 1.0 |
| 徐晨 | 2022.7.3 | 完成部分业务逻辑层分解 | 1.1 |
| 徐晨 | 2022.7.3 | 完善业务逻辑层分解，完成数据层分解 | 1.2 |
| 徐晨 | 2022.7.6 | 完善模块职责中层之间的调用接口 | 1.3 |
| 徐晨 | 2022.7.6 | 完善客户端各层的职责，添加运行时进程图、物理部署图 | 1.4 |
| 徐晨 | 2022.7.7 | 完善逻辑视图 | 1.5 |
| 徐晨 | 2022.7.8 | 完善逻辑视图、信息视角、物理部署 | 1.6 |
| 徐晨 | 2022.7.9 | 完善业务逻辑层分解 | 1.7 |
| 徐晨 | 2022.7.10 | 修改PO对象的int类型为Integer类型 | 1.8 |
| 徐晨 | 2022.7.10 | 完善业务逻辑层分解 | 1.9 |
1. 引言
1.1 编制目的
本报告详细完成对ERPS的详细设计，达到指导后续软件构造的目的，同时实现和测试人员及用户的沟通。本报告面向开发人员、测试人员及最终用户而编写，是了解系统的导航。
1.2 词汇表
| 词汇名称 | 词汇含义 | 备注 |
|---|---|---|
| ERPS | 企业资源计划系统 |
1.3 参考资料
- 企业资源计划系统（ERPS）用例文档
- 企业资源计划系统（ERPS）软件需求规格说明文档
- 企业资源计划系统（ERPS）详细设计文档
- 软件工程与计算（卷二）：软件开发的技术基础
2. 产品概述
参考用例文档和软件需求规格说明中对产品的概括描述3. 逻辑视角
ERPS中，选择了分层体系结构风格，将系统分为3部分（presentation、bussiness、data）能够很好地示意整个高层抽象。presentation部分包含GUI页面的实现，bussiness部分负责业务逻辑的实现，data部分负责数据的持久化和访问。分层体系结构的逻辑视角和逻辑设计方案如下图所示。
图1 软件体系结构逻辑设计方案4. 组合视角
4.1 开发包图
| 开发包 | 依赖的其他开发包 | | —- | —- | | salesui | salesbl | | commodityui | commoditybl | | financeui | financebl | | memberui | memberbl | | promotionui | promotiondata | | salesbl | memberbl、financebl、promotionbl、commoditybl、salesdata | | commoditybl | salesbl、financebl、commoditydata | | financebl | memberbl、salesbl、commoditybl、financedata | | memberbl | salesbl、commoditybl、memberdata | | promotionbl | promotiondata | | element-ui | | | Mybatis | JDBC | | REST API | |
4.2 运行时进程
- 表示软件在运行时进程间的交互，描述系统的动态结构
- 绘制进程图
示意图：
处理如何将软件组件映射到硬件基础设施
示意图：
模块视图
- 网络模块
- 启动模块
- presentation层
- bussiness层
- data层
客户端各层的职责 | 层 | 职责 | | —- | —- | | 启动模块 | 负责初始化网络通信，渲染浏览器界面 | | presentation层 | 基于浏览器窗口的ERPS客户端用户界面 | | bussiness层 | 对于用户界面的输入和选择进行响应并进行业务处理逻辑 | | 网络模块 | 利用REST API和服务器端交互 |
服务端各层的职责 | 层 | 职责 | | —- | —- | | 启动模块 | 负责初始化通络通信机制，加载Bean | | 服务器端网络模块 | 利用Tomcat和Java注解与反射开启服务器端接口 | | 拦截器层 | 自定义拦截器，借助jwt进行用户身份校验，拦截除登录注册外的api | | bussiness层 | 实现业务逻辑 | | data层 | 负责数据的持久化及数据访问接口 |
5.2 数据层的分解
数据层主要给业务逻辑层提供数据访问服务，包括对于持久化数据的增删改查，持久化数据的保存方式是采用MySQL数据库
数据层的职责
| 模块 | 职责 |
|---|---|
| commoditydata | 基于MySQL数据库的product表族的接口，提供增删改查服务 |
| salesdata | 基于MySQL数据库的sale表族的接口，提供增删改查服务 |
| financedata | 基于MySQL数据库的salary表族的接口，提供增删改查服务 |
| memberdata | 基于MySQL数据库的user表族的接口，提供增删改查服务 |
| promotiondata | 基于MySQL数据库的voucher表族的接口，提供增删改查服务 |
6. 信息视角
- 数据持久化对象
- User类包含用户的编号（Integer，主键）、姓名（String）、密码（String）、用户名（String）、电话号码（String）、用户类型（枚举类型UserType）、工作岗位（枚举类型JobType）、薪资计算方式（Integer）
- Voucher类包含促销策略的编号（Integer，主键）、描述（String）、促销策略类型（枚举类型VoucherType）、促销获取门槛（double）、折扣（double）、优惠金额（double）、优惠券（枚举类型CouponType）、可用时间（LocalDateTime）、失效时间（LocalDateTime）
- Sheet类包含单据的编号（Integer，主键）、描述（String）、单据类型（枚举类型SheetType）、银行账户（String）、金额（double）、时间（LocalDateTime）、是否批准通过（boolean）、单据状态（String）
企业资源计划系统（ERPS）详细设计文档
0. 文档修改历史
| 修改人员 | 日期 | 修改原因 | 版本号 | | —- | —- | —- | —- | | 徐晨 | 2022.7.2 | 创建文档、添加引言、产品概述、体系结构设计概述 | 1.0 | | 徐晨 | 2022.7.6 | 添加financebl的业务逻辑层分解 | 1.1 | | 徐晨 | 2022.7.7 | 添加financebl的需接口 | 1.2 |
1. 引言
1.1 编制目的
本报告详细完成对ERPS的详细设计，达到指导后续软件构造的目的，同时实现和测试人员及用户的沟通。本报告面向开发人员、测试人员及最终用户而编写，是了解系统的导航。
1.2 词汇表
| 词汇名称 | 词汇含义 | 备注 |
|---|---|---|
| ERPS | 企业资源计划系统 |
1.3 参考资料
- 企业资源计划系统（ERPS）用例文档
- 企业资源计划系统（ERPS）软件需求规格说明文档
- 企业资源计划系统（ERPS）体系结构文档
- 软件工程与计算（卷二）：软件开发的技术基础
2. 产品概述
参考用例文档和软件需求规格说明中对产品的概括描述3. 体系结构设计概述
参考体系结构文档中对体系结构设计的概述4. 结构视角
4.1 业务逻辑层的分解
4.1.1 financebl模块
- 模块概述
- finance模块承担的需求参见需求规格说明文档功能需求及相关非功能需求
- 整体结构
- 根据体系结构的设计，我们将系统分为展示层、业务逻辑层、数据层。每一层之间为了增加灵活性，我们会添加接口。比如展示层和业务逻辑层之间，我们添加service.CategoryService接口。业务逻辑层和数据层之间添加service.findCustomerById接口。SalesPO 是作为销售、进货、销售退货、进货退货记录的持久化对象被添加到设计模型中去的。 | 模块 | 职责 | | —- | —- | | Sheet | 单据的领域模型对象，拥有单据的编号、描述、单据类型、银行账户、金额、时间、单据状态等信息 | | User | 系统用户的领域模型对象，拥有用户数据的姓名和密码，可以解决登录问题 | | Customer | 客户的领域模型对象，拥有客户的姓名、银行账户、应收等信息 |
表1 finance模块各个类的职责
| FinanceService.createAccount | 语法：void createAccount(AccountVO accountVO); 前置条件：已创建一个FinanceService领域对象，输入符合规则 后置条件：调用financeDao.createAccount(AccountVO accountVO); |
|---|---|
| FinanceService.deleteAccount | 语法：int deleteAccount(String name); 前置条件：已创建一个FinanceService领域对象，输入符合规则 后置条件：调用financeDao.deleteAccount(String name); |
| FinanceService.searchAccounts | 语法：List 前置条件：已创建一个FinanceService领域对象，输入符合规则 后置条件：调用financeDao.findByWord(String word) |
| FinanceService.approval | 语法：void approval(String sheetId, SheetState state, SheetService sheetService); 前置条件：已创建一个FinanceService领域对象，输入符合规则 后置条件：调用sheetService.approval(String sheetId, sheetState state, FinanceDao financeDao, CustomerDao customerDao) |
| FinanceService.getSheetByState | 语法：List 前置条件：已创建一个FinanceService领域对象，输入符合规则 后置条件：调用sheetService.getSheetByState(sheetState state, FinanceDao financeDao); |
| FinanceService.makeCollectSheet | 语法：void makeCollectSheet(CollectSheetVO collectSheetVO); 前置条件：已创建一个FinanceService领域对象，输入符合规则 后置条件：调用financeDao.saveCollectSheet(collectSheetPO); financeDao.saveTransferContents(transferContentPOS); |
| FinanceService.makePaySheet | 语法：void makePaySheet(PaySheetVO paySheetVO); 前置条件：已创建一个FinanceService领域对象，输入符合规则 后置条件：调用financeDao.savePaySheet(paySheetPO); financeDao.saveTransferContents(transferContentPOS); |
| FinanceService.makeSalarySheet | 语法：void makeSalarySheet(SalarySheetVO salarySheetVO); 前置条件：已创建一个FinanceService领域对象，输入符合规则 后置条件：调用financeDao.saveSalarySheet(salarySheetPO); |
| FinanceService.makeCashSheet | 语法：void makeCashSheet(CashSheetVO cashSheetVO); 前置条件：已创建一个FinanceService领域对象，输入符合规则 后置条件：调用financeDao.saveCashSheet(cashSheetPO); financeDao.saveCashContents(cashSheetContentPOS); |
| FinanceService.getSalarySum | 语法：BigDecimal getSalarySum(); 前置条件：已创建一个FinanceService领域对象，输入符合规则 后置条件：调用financeDao.getSalarySum(); |
5. 依赖视角
参考体系结构文档中的依赖
若有收获，就点个赞吧
0 人点赞
