旅游业务申请系统用例图和用例文档

表1给出了旅游申请系统中“办理申请手续”用例的文档。由于该用例中并没有明确的非功能需求，因此在文档中也没有体现。

表1 “办理申请手续”用例文档

用例名	办理申请手续
简要描述	前台服务员通过该用例为申请人办理申请旅游团的手续
参与者	前台服务员
涉众	申请人、前台服务员
相关用例	暂无
前置条件	前台服务员登录到系统
后置条件	申请信息被正确保存，相关旅游团可申请人数减少
基本事件流 1. 该用例起始于旅客需要办理申请手续； 2. 前台服务员录入要申请的旅游团旅行路线代码和出发日期； 3. 系统查询要申请的旅游团信息（A-1）； 4. 系统显示查询到的旅游团和相关路线信息（D-1）（A-2、A-3）； 5. 前台服务员录入本次申请信息（D-2）； 6. 系统显示旅行费用的总额和申请订金金额； 7. 前台服务员提交该申请信息； 8. 系统保存该申请信息（A-4），用例结束。
备选事件流 A-* 前台服务员在提交该申请前，随时都可能中止该申请 1. 系统显示中止确认的消息； 2. 前台服务员可以结束该用例，也可以选择继续录入下一个申请。 A-1 无法查询到所需的旅游团信息 1. 系统显示录入的旅游线路代码或者出发日期有误信息； 2. 前台服务员再次录入旅游路线代码和出发日期，也可以结束用例。 A-2 旅行已超过申请截止日期 1. 系统提示已超过申请截止日期，不能申请； 2. 前台服务员重新输入旅游线路代码和新的出发日期，也可以结束用例。 A-3 可以申请的人数为0人 1. 系统提示旅游团人数已满； 2. 前台服务员重新输入新的旅游线路代码和出发日期，也可以结束用例。 A-4 保存信息失败 1. 系统显示保存失败，并提示用户需要再次提交； 2. 前台服务员可以重新提交该申请，也可以结束用例。
补充约束-数据需求 D-1 显示的旅游团和路线信息包括：旅游路线代码、旅游路线名称、出发日期、天数、申请截止日、可申请人数、大人的单价和小孩的单价等。 D-2 录入申请信息包括：申请责任人的姓名、电话号码、参加的大人人数、小孩人数 补充约束-业务规则 B-1 所申请旅游团的截止日期在申请日期之前 B-2 所申请旅游团的人数限额未满 B-3 申请订金的计算规则如下表所示： 距出发日期的天数 订金比例 ≥2个月 10% ≥1个月，且<2个月 20% <1个月 全款
待解决问题 （暂无）
相关图 （暂无）

表2给出了“管理参加人”用例文档，与前一个用例文档不同的是，该用例文档的基本事件流被划分成三个子流程，通过子流程的方式可以使该用例文档的结构更加清晰。

表2 “管理参加人”用例文档

用例名	管理参加人
简要描述	前台服务员通过该用例为对申请参加人的信息进行维护
参与者	前台服务员
涉众	申请人、申请参加人
相关用例	暂无
前置条件	前台服务员登录到系统
后置条件	申请参加人的信息被正确的录入到系统中
基本事件流 1. 用例起始于前台服务员需要对申请的参加人信息进行维护； 2. 前台服务员输入查询条件（D-1），查询申请信息； 3. 系统查询该申请（A-1），并显示申请详细信息（D-2）； 4. 前台服务员选择所要进行的操作； 5. 系统根据前台服务员选择的操作，执行以下的子流程： 选择“增加参加人”操作时，开始“增加参加人”子流程（S-1）； 选择“修改参加人”操作时，开始“修改参加人”子流程（S-2）； 选择“删除参加人”操作时，开始“删除参加人”子流程（S-3）； 6. 子流程完成后，用例结束。 子流程S-1：增加参加人 1. 系统显示申请责任人的姓名和电话号码； 2. 前台服务员录入申请责任人信息（D-3）； 3. 前台服务员录入申请责任人旅行途中的联络人信息（D-4）； 4. 前台服务员继续录入其它参加人的信息； 5. 前台服务员录入参加人信息（D-3）； 6. 前台服务员录入参加人有关旅行途中的联络人信息（D-4）； 7. 重复步骤5.6，录入所有的参加人（A-2）； 8. 前台服务员提交本次录入信息（A-3）； 9. 系统保存参加者信息（A-4），结束该子流程。 子流程S-2：修改参加人 1. 系统显示全部参加人的姓名； 2. 前台服务员选出要修改的参加人； 3. 系统显示要变更的参加者信息（D-3）和联络人信息（D-4）； 4. 前台服务员修改相关的信息； 5. 前台服务员提交本次修改（A-2）； 6. 系统保存参加人信息，结束该子流程。 子流程S-3：删除参加人 1. 系统显示全部参加人的姓名； 2. 前台服务员选出删除的参加人； 3. 系统显示取消手续费用和返还金额； 4. 前台服务员确认删除； 5. 系统保存本次删除信息； 6. 若删除的参加人就是申请责任人，为了选择新的申请责任人，系统会显示所有参加人的姓名； 7. 前台服务员选择新的申请责任人； 8. 系统录入新的申请责任人（A-4），结束该子流程。
备选事件流 A-* 前台服务员在操作提交之前，随时都能够结束子流程 1. 系统显示确认中止的消息； 2. 前台服务员可以结束子流程，也可选择继续其它操作。 A-1 没有找到申请信息 1. 系统提示未找到该申请信息 2. 前台服务员输入查询条件进行查询，也可以结束用例。 A-2 必填项有未输入项目 1. 系统提示有未输入项目； 2. 前台服务员再次输入未输入项。 A-3 尚未录入所有参加者的信息 1. 系统提示有未录入的参加者信息； 2. 前台服务员可以继续录入参加者的信息，也可登录目前已录入的参加者的信息，结束子流程。 A-4 系统保存失败 1. 系统提示保存失败； 2. 前台服务员可以再次提交，也可结束该用例
补充约束-数据需求 D-1 查询条件包括：旅游线路代码、出发日期、申请责任人姓名 D-2 显示的申请信息包括：旅游线路代码、旅游团名称、出发日期、申请日期、申请责任人姓名、支付情况。 D-3 参加人信息包括：性别、出生年月、现在住所、邮政编码、A-Mail地址等 D-4 联络人信息包括：姓名、与本人关系、住址、邮政编码、电话号码等； 补充约束-业务规则 B-1 取消手续费如下表所示： 距出发日期的天数 取消手续费用 1个月以上 无 1个月到10天 20% 10天到1天（前一天） 50% 0天（出发当天） 全款 距出发日期的天数 取消手续费用
待解决问题 （暂无）
相关图 （暂无）

表3给出了“完成支付”用例文档。从用例文档可以看出，该用例文档和“管理参加人”用例文档的基本事件流中存在很多相似的地方，即都需要查询申请的信息；在下一节将介绍如何处理这种情况。

表3 “完成支付”用例文档

用例名	完成支付
简要描述	前台服务员通过该用例录入申请的费用支付信息
参与者	前台服务员
涉众	前台服务员、申请参加人
相关用例	暂无
前置条件	前台服务员登录到系统
后置条件	申请的支付信息被正确的录入到系统中
基本事件流 1. 用例起始于申请参加人来交费，前台服务员需要录入申请的支付信息； 2. 前台服务员可根据交款单编号或者申请信息（D-1），查询已经录入的申请； 3. 系统查询该申请（A-1），并显示申请详细信息（D-2）； 4. 前台服务员选择完成支付功能； 5. 系统显示录入支付信息界面； 6. 前台服务员录入费用的支付信息； 7. 系统保存费用支付信息（A-2），用例结束。
备选事件流 A-* 前台服务员在操作提交之前，随时都能够结束支付流程 1. 系统显示确认录入终止的信息； 2. 前台服务员可以结束用例，也可以选择继续。 A-1 没有找到申请信息 1. 系统提示未找到该申请信息； 2. 前台服务员输入查询条件进行查询，也可以结束用例。 A-2 保存失败 1. 系统显示保存失败； 2. 前台服务员可以选择再次提交，也可以结束该用例。
补充约束-数据需求 D-1 查询申请信息包括：旅游线路代码、出发日期、申请责任人姓名； D-2 显示的申请信息包括：旅游线路代码、旅游团名称、出发日期、申请责任人的姓名、余款金额、支付期限等信息。 补充约束-非功能需求 可扩展性：目前的支付方式是现金支付，可预见的变化是考虑通过信用卡进行网上支付
待解决问题 （暂无）
相关图 （暂无）

表4给出了系统中另一个参与者“收款员工”参与的用例“打印旅游确认书和余额交款单”的用例文档，注意在该用例文档的基本事件流的第3步中如何表示循环操作。

表4 “打印旅游确认书和余额交款单”用例文档

用例名	打印旅游确认书和余额交款单
简要描述	收款员工每天通过该用例打印前一天所有申请的旅游确认书和余额交款单
参与者	收款员工
涉众	收款员工、申请责任人
相关用例	暂无
前置条件	收款员工登录到系统
后置条件	设置申请状态为已发送确认书，对于支付全款的申请，其状态修改为已支付完成
基本事件流 1. 用例起始于收款员工准备为申请人打印旅游确认书和余额交款单； 2. 系统查询前一天为止已经完成申请并且尚未打印确认书的申请； 3. 对于查询到的全部申请，系统重复执行步骤4~6步： 4. 系统打印旅游团确认书（D-1）； 5. 对于有余款未支付的申请，系统打印交款单（D-2）；对于旅费已全部支付的申请，设其状态为完成支付； 6. 系统设置该申请为已经发行确认书的状态。 7. 全部申请均处理完成后，用例结束。
备选事件流 （暂无）
补充约束-数据需求 D-1 旅游确认书包括：收信人信息（即申请负责人的姓名、邮编、当前住址）和对应的旅游团信息（即旅游线路编码、旅游线路名称、出发日期、全体参加人的名称）； D-2 交款单内容包括：交款单编号、旅游团的单价、参加者人数、合计金额、订金、余款、支付期限等。
待解决问题 （暂无）
相关图 （暂无）

表5给出了“导出财务信息”用例文档。由于该用例的参与者是时间和财务系统，没有外部用户，所以事件流中全是系统的动作。此外，由于问题陈述中并没有提及有关财务系统的相关细节，因此与财务系统的交互模式也无法表示清楚。

表5 “导出财务信息”用例文档

用例名	导出财务信息
简要描述	系统每天晚上自动导出当头的财务信息，并导入到财务系统中
参与者	时间，财务系统（辅参与者）
涉众	会计人员
相关用例	暂无
前置条件	无
后置条件	所有当天的财务信息均被正确导入到财务系统中
基本事件流 1. 用例起始于系统每天晚上自动运行； 2. 系统查询当天所收取的所有订金和支付信息（A-1）； 3. 针对所有的订金和支付信息，重复执行4~5步： 4. 系统获取当前的订金和支付信息； 5. 系统将这些订金和支付信息导出到财务系统中（A-2）； 6. 全部费用信息处理完成后，当前用例结束。
备选事件流 A-1 没有订金和支付信息，当前用例中止。 A-2 导出过程出错，记录出错日志，并继续导入下一条信息。
补充约束-业务规则 B-1 该用例自动运行的时间可以由用户设定。 B-2 导出过程出现异常时应能够自动处理，并继续后续的操作，并记录相应的日志
待解决问题 P-1 有关导出数据的内容、格式和实现技术还需要与财务系统开发方进一步商定。 P-2 有关错误日志的格式有待进一步确定。
相关图 （暂无）