说明：这是3人团队作品，我发出的内容都是我自己写的部分与和团队队员一起讨论的部分，有删减其它队员的内容，文章不是很完整，但是我写的内容比较有参考性可以补充剩下的内容。发出的图是我原创的。
类图：软件工程-大学体育馆管理系统类图_刘建杰的博客-CSDN博客
交互图：软件工程-大学体育馆管理系统交互图_刘建杰的博客-CSDN博客
本科学生设计性实验报告
项目组长 学号
成 员
专 业 班级
实验项目名称 大学体育场馆管理系统
指导教师及职称
开课学期 2021 至 2022 学年 2 学期
上课时间 2022 年 3 月 10 日
大学体育场馆管理系统用例建模
一、摘要
通过本实验掌握小型应用系统开发文档的建立，具体包含如下内容：
1.确定参与者；
2.确定参与者职责；
3.建立初步用例图；
4.精化用例图；
5.用例描述。
二、实验目的及要求
1、掌握小型系统需求获取和分析；
2、掌握用例建模；
三、实验仪器设备
计算机+Office
四、实验方案设计
经过调研与可行性分析，出于对大学生的健康运动合理分配需求，设计了体育馆管理系统，本系统主要针对大学生对体育馆的合理分配使用。该系统主要包括：
(1)体育馆的场地管理如添加、删除、修改场地信息等。
(2)用户（江财师生、游客）可以登录系统，查看体育馆的场地状态及预约情况
(3)用户可以通过系统预约馆内场地。
(4)运维人员按照系统通知进行相应维护。
(5)收银员根据系统进行收费。
这样就可以便于对体育馆进行全面的了解和管理。
五、实验内容及步骤
（一）确定参与者
1、系统管理员
2、普通管理员
3、收银员
4、运维人员
5、客户（江财学生、老师及游客）
6、学生信息管理系统
7、第三方支付系统
- 确定用例
1、系统管理员
（1）普通管理员的管理
a.普通管理员的添加
b.普通管理员的查询
c.普通管理员的删除
d.普通管理员的修改
（2）设置系统备份与系统恢复
（3）用户(普通管理员、师生、游客、运维人员、收银员)权限管理。
2、普通管理员
(1)客户（师生游客）基本信息管理
a.客户基本信息的修改
b.客户基本信息的查询
c.客户基本信息的删除
(2) 场地管理（包括场馆内各个运动项目场地）
a.场地基本信息的录入
b.场地基本信息的查询
c.场地基本信息的删除
d.场地基本信息的修改
(3)收银员运维人员管理
a.收银员运维人员信息的添加
b.收银员运维人员信息的修改
c.收银员运维人员信息的删除
b.收银员运维人员信息的查询
3、收银员
(1)场地开单
(2)修改订单
(3)查询订单
(4)预约查询
(5)收款
4、运维人员
(1)场地故障信息的修改
(2)场地故障信息的删除
(3)场地故障信息的查询
(4)记录维修记录
5、江财师生及游客
(1)注册账号
(2)登录账号
(3)查看个人中心
(4)修改本人基本信息
(5)场地预约
(5)预约查询
(6)场地查询
(7)订单查询
(8)取消预约
(9)订单续约
(10)订单结账
(11)付款
(12)故障上报
6、学生信息管理系统
(1)核查信息
7、第三方支付系统
(1)支付
- 用例图
图 1 精化用例图
- 用例描述
少了部分用例描述
| 用例名称 | 客户用户注册账号 |
| 用例编号 | UC3-1 |
| 参与者 | 全体江财师生及外来游客。 |
| 用例描述 | 全体江财师生及外来游客注册系统。 |
| 触发器 | 客户注册成功时，用例触发 |
| 前置条件 | 全体江财师生及外来游客用户已打开系统。 |
| 后置条件 | 无 |
| 基本事件流 | 1:全体江财师生及外来游客请求注册用户。 2:系统显示注册页面，提示用户输入注册信息。 3:全体江财师生及外来游客输入用户注册信息，并点击“提交”。 4:全体江财师生及外来游客输入用户信息是否符合规则， 针对江财师生输入的一卡通号或工号调用师生信息管理系统提供的审核信息接口审核输入是否正确。 如果符合，则注册成功。 5:系统自动保存新建用户信息。 |
| 扩展事件流 | 1:用户取消注册。 2:用户信息不符合规则，给出提示信息，要求重新输入。 3:用户不同意注册条款，系统自动关闭注册。 |
| 结论 | 只要用户信息符合系统规则，即可注册成功。 |
| 数据需求 | 系统管理员账户密码 |
| 业务规则 | 无 |
表 11 用例描述11
| 用例名称 | 故障上报 |
| 用例编号 | UC3-8 |
| 参与者 | 客户 |
| 用例描述 | 客户使用运动场地时发现场地存在故障，上报故障信息所执行的用例 |
| 触发器 | 客户点击故障上报功能时用例触发。 |
| 前置条件 | 客户登陆系统。 |
| 后置条件 | 无 |
| 基本事件流 | 1:客户登录系统点击故障上报功能。 2:系统弹出页面，客户根据实际情况输入具体故障信息 3:客户点击确定上报 |
| 扩展事件流 | 如果客户输入非法，系统提示客户重新输入 |
| 结论 | 当客户收到系统故障上报成功提示，用例结束 |
| 数据需求 | 故障信息应包括：标题、场地编号、场地名称、故障类型、故障描述、证明图片、状态 |
| 业务规则 | 无 |
表 18 用例描述18
| 用例名称 | 场地开单 |
| 用例编号 | UC4-1 |
| 参与者 | 收银员 |
| 用例描述 | 该用例描述收银员根据预约信息或者客户临柜执行场地开单的行为 |
| 触发器 | 当收银员点击系统场地开单功能时，用例触发 |
| 前置条件 | 点击场地开单的收银员需要先完成登录操作 |
| 后置条件 | 如果开单信息正确，生成并保存订单； |
| 基本事件流 |
(3) 收银员输入或选择额外待填的信息，如：出租的器材类型、数量、备注等，确认无误后点击开单
|
| 扩展事件流 | 1. 如果表格信息合法系统将获取当前时间作为订单的开场时间，并保存订单信息 2. 如果收银员输入信息或者订单信息有误，系统通知收银员重新输入 3. 如果收银员选择了出租器材类型，系统应显示对应选择的器材待出租数量，当器材待出租数量为0时给出相应提示 |
| 结论 | 当收银员收到系统发送的开单成功提示，用例结束 |
| 数据需求 | 场地开单应包括场地类型、场地编号、预离时间、开场时间、备注信息、使用场地的用户姓名、出租器材数量等 |
| 业务规则 | 无 |
表 19用例描述19
| 用例名称 | 查询订单 |
| 用例编号 | UC4-2 |
| 参与者 | 收银员 |
| 用例描述 | 该用例描述客户租用场地后，临柜查询订单信息了解已消费金额等信息 |
| 触发器 | 当收银员点击订单查询功能时，用例触发 |
| 前置条件 | 点击场地开单的收银员需要先完成登录操作 |
| 后置条件 | 无 |
| 基本事件流 | 1.收银员点击查询订单功能按钮跳转到订单列表界面 2.系统默认列出当前所有在用的订单列表 3.收银员可根据客户提供的场地类型、场地编号、用户姓名、电话等精确查找匹配的订单 4.收银员点击订单详细 5.系统弹出订单信息 |
| 扩展事件流 | 如果收银员输入非法关键字搜索，系统给出相应提示 |
| 结论 | 当收银员查看到系统给出的要查询的订单信息，用例结束 |
| 数据需求 | 查询后的订单信息应包括场地类型、预离时间、开场时间、使用时间、应付金额、备注信息等 |
| 业务规则 | 无 |
表 20用例描述20
| 用例名称 | 修改订单 |
| 用例编号 | UC4-3 |
| 参与者 | 收银员 |
| 用例描述 | 该用例描述客户租用场地后，临柜需更换场地或者收银员需要修改备注等信息 |
| 触发器 | 当收银员点击修改订单时，用例触发 |
| 前置条件 | 收银员需要先查询到需要修改的订单信息 |
| 后置条件 | 如果修改订单信息正确，修改订单成功； |
| 基本事件流 | 1.收银员在订单详细或订单列表界面点击修改订单 2.系统弹出订单已有的基本信息，其中开场时间、应收金额应不可更改 3.收银员可根据客户需要器材出租、选择新的场地更换场地，编辑备注信息等 4.收银员点击确定修改 |
| 扩展事件流 | 1. 如果收银员输入的信息有误，系统通知收银员重新输入 2. 如果收银员选择了出租器材类型，系统应显示对应选择的器材待出租数量，当器材待出租数量为0时给出相应提示 |
| 结论 | 当收银员收到系统发送的修改订单成功提示，用例结束 |
| 数据需求 | 修改的订单信息应包括场地类型、预离时间、开场时间、使用时间、应付金额、备注信息等 |
| 业务规则 | 无 |
表 21用例描述21
| 用例名称 | 收款结账 |
| 用例编号 | UC4-4 |
| 参与者 | 收银员 |
| 用例描述 | 客户临柜结算，收银员使用系统为客户办理结账手续 |
| 触发器 | 当收银员点击收款结账功能时，用例触发 |
| 前置条件 | 收银员需要先查询到需要结账的订单信息 |
| 后置条件 | 如果系统收款成功，订单变为结束状态 |
| 基本事件流 | 1.收银员在订单详细或订单列表界面点击收款结账按钮 2.系统根据客户类别，若是师生计算管理员设置的优惠价格 3.系统弹出要付款的订单信息 3.收银员选择对应的收款方式：现金、网上支付 4.收银员点击确定收款结账按钮 5.1若3是现金支付 在现实中收银员收到客户交付的现金 5.2若3是网上支付 在现实中收银员手持统一扫码设备扫客户付款二维码后，系统调用第三方支付平台系统完成收款 |
| 扩展事件流 |
|
| 结论 | 当收银员收到系统收款成功提示，用例结束 |
| 数据需求 | 要付款的订单信息包括，场地类型、预离时间、开场时间、使用时间、应付金额、优惠价格、备注信息等 |
| 业务规则 | 无 |
表 22用例描述22
| 用例名称 | 场地故障信息修改 |
| 用例编号 | UC5-1 |
| 参与者 | 运维人员 |
| 用例描述 | 运维人员根据客户提供的故障信息，到现场核实故障后，但发现客户填写的故障描述不符合或者描述不清具体的故障情况所执行的行为 |
| 触发器 | 当运维人员点击场地故障信息修改功能时，用例触发 |
| 前置条件 | 运维人员需要先查询到需要修改的场地故障信息 |
| 后置条件 | 无 |
| 基本事件流 | 1.运维人员在故障信息详细或故障信息列表界面点击修改场地故障信息 2.系统弹出客户已填好的故障基本信息 3.运维人员在故障描述文本框输入符合具体情况的故障描述，以及根据需要修改其它故障基本信息 4.运维人员点击确定修改 |
| 扩展事件流 | 如果运维人员输入描述非法或超字符限制等情况，系统提示运维人员重新修改 |
| 结论 | 当运维人员收到系统修改成功提示，用例结束 |
| 数据需求 | 客户上报的故障信息应包括，故障序号、上报人、上报时间、场地编号类型、故障类型、故障描述、故障状态等 |
| 业务规则 | 无 |
表 23用例描述23
| 用例名称 | 录入场地故障维修记录 |
| 用例编号 | UC5-2 |
| 参与者 | 运维人员 |
| 用例描述 | 运维人员根据客户提供的故障信息，到现场核实并做出维修处理后，记录此维修记录所执行的行为 |
| 触发器 | 当运维人员点击录入场地故障维修记录时，用例触发 |
| 前置条件 | 运维人员需要先查询到需要处理的场地故障信息 |
| 后置条件 | 如果录入信息成功，对应的场地故障信息状态应改为已处理 |
| 基本事件流 | 1.运维人员在故障信息详细或故障信息列表界面点击录入场地故障维修记录 2.系统弹出新页面，显示出客户已填好的故障基本信息 3.运维人员填入或选择维修的基本信息 4.运维人员点击录入完成 |
| 扩展事件流 | 如果运维人员非法输入，系统提示运维人员重新录入 |
| 结论 | 当运维人员收到系统录入成功提示，用例结束 |
| 数据需求 | 维修的基本信息应包括，对应的故障信息Id、维修人、维修时间、维修所耗物品、维修所耗金额、维修结果（成功还是失败） |
| 业务规则 | 无 |
表 24用例描述24
| 用例名称 | 器材信息添加 |
| 用例编号 | UC5-3 |
| 参与者 | 运维人员 |
| 用例描述 | 运维人员对馆内的各个器材记录信息到系统内，所执行的行为 |
| 触发器 | 当运维人员点击器材信息添加功能时，用例触发 |
| 前置条件 | 运维人员需要完成登录操作 |
| 后置条件 | 无 |
| 基本事件流 | 1.运维人员在点击器材信息添加后 2.系统弹出添加器材页面 3.运维人员填入器材的基本信息，如：名称、类型 4.运维人员点击确定添加 |
| 扩展事件流 | 如果运维人员输入非法，系统提示运维人员重新输入 |
| 结论 | 当运维人员收到系统添加成功提示，用例结束 |
| 数据需求 | 器材的基本信息应包括：名称、类型、数量、寿命、添加时间、状态等 |
| 业务规则 | 无 |
表 25用例描述25
| 用例名称 | 器材信息修改 |
| 用例编号 | UC5-4 |
| 参与者 | 运维人员 |
| 用例描述 | 运维人员对馆内器材信息进行更新所执行的行为 |
| 触发器 | 当运维人员点击器材修改功能时，用例触发 |
| 前置条件 | 运维人员需要先查询到需要修改的器材信息 |
| 后置条件 | 无 |
| 基本事件流 | 1.运维人员在器材信息详细或器材信息列表界面点击修改器材信息 2.系统弹出页面，显示对应器材在馆内的基本信息 3.运维人员填入器材的新的信息，如：数量 4.运维人员点击确定修改 |
| 扩展事件流 | 如果运维人员输入非法，系统提示运维人员重新输入 |
| 结论 | 当运维人员收到系统修改成功提示，用例结束 |
| 数据需求 | 要修改的器材的信息应包括：名称、类型、数量、添加时间、状态等 |
| 业务规则 | 无 |
表 26用例描述26
- 结果与讨论
924
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
