- 1可以与宝塔共存的一个 “魔法” 服务器状态监控应用 ——xui_xui面板
- 2opencv3.2 增加opencv_contrib组件_opencv_contrib升级
- 3【ROS2机器人入门到实战】_ros2机器人编程实战 pdf
- 4使用Pytorch和OpenCV实现视频人脸替换_facial_transformation_matrixes:
- 5leetcode 重做_leetcode 创建新做题进度,恢复默认
- 6Ldap和jira集成应用_企业微信 ldap jira
- 7如何解决form表单循环添加一组数据
- 8centos7安装+nvidia驱动+cuda+cudnn安装_cudnn rpm 安装
- 9C语言详解
- 10随机森林回归模型算法_model = randomforestregressor()
UML预约挂号系统建模（团队作业）_挂号系统顺序图
赞
踩
若对你有帮助，记得点赞、关注我哦！
博文总领目录请看这篇，无敌干货
软件工程专业大学四年学什么_大学近代史学分是多少-CSDN博客
https://blog.csdn.net/qq_41587612/article/details/104362661B站同名up猪，欢迎关注我的账号鸽子不二的个人空间-鸽子不二个人主页-哔哩哔哩视频哔哩哔哩鸽子不二的个人空间，提供鸽子不二分享的视频、音频、文章、动态、收藏等内容，关注鸽子不二账号，第一时间了解UP主动态。https://space.bilibili.com/204913846
根据以下资料，进行业务建模、用例建模、用例分析。团队自制，没有答案！有些部分不能保证质量，望高人指点改进！
具体要求：
1. 根据现有业务描述，识别业务参与者、业务用例，建立业务用例模型，用活动图描述业务用例；
识别业务工人，用类图描述业务工人和业务实体，以及它们之间的关系，建立业务对象模型；
2. 根据新系统的要求和相关业务理解，识别参与者，识别用例，建立用例模型，完成系统用例图和核心用例的用例文档；
3. 对核心用例进行分析，按照MVC架构识别分析类，建立参与类类图，分析用例实现，建立用例交互模型。
业务描述：
患者到医院门诊看病需要挂号，不同的专科门诊每天的坐诊医生不同，医生职级分为：专家、主任医师、主治医师，不同职级医生的挂号费不同，患者到医院看病首先要填写病历本（患者信息），如果知道自己需要看那一科，就直接到挂号窗口挂号，如果不确定自己应该到那科看病，可以描述自己的病情咨询导诊台护士，然后再到窗口挂号。
挂号时，窗口工作人员会告知患者所选专科门诊有那些职级医生坐诊，患者可以选择挂那一个职级医生的号，交挂号费后，挂号窗口工作人员会将挂号收据和诊疗卡给患者，患者就可以去看病了。如果患者在医生看诊之前不想看病了，可以到挂号窗口退号，工作人员核实信息后，退还患者挂号费。
需求描述：
为了规范和推动医院预约挂号服务.卫生部2009年8月在其官方网站发布了(关于在公立医院施行预约诊疗服务工作的意见(征求意见稿)》，要求在推动医院开展预约挂号工作的同时，提高对预约挂号服务工作的认识、加强对预约挂号服务工作的管理并认真做好相关组织工作。
某IT公司瞄准此次契机，决定着手开发一个通用的“医院预约挂号系统”，以满足各级公立医院的预约挂号需求。该挂号系统1期目标是实现计算机网上预约业务，后续计划会逐步实现手机上网预约、短信预约、自助预约机预约、自助电话预约等其他形式的预约业务。
系统的基本流程如下。未注册用户可以通过该系统查询医院、相关科室、各科室的医生等各类信息，但不能使用其他与预约相关的业务。需要进行预约挂号的用户必须通过该网站利用身份证号进行实名注册，注册信息由系统管理员进行审核，审核通过后，用户才可使用该系统。
预约挂号时,用户首先选择需要预约的医院,然后选择要预约的科室和时间(指定某个日期的上午或下午)，此时，系统应自动显示该时间段内该科室所有出诊的医生。需要注意的是，每个医生每次出诊所能看病的人数有一定的限制,当某个医生的预约人数满员后即不可预约。用户可以选择一个可预约的医生进行预约，一个用户每个时间段最多只能预约5位医生。预约成功后,用户可以打印预约单。用户可以通过第三方的支付系统(1期只支持淘宝的支付宝，后续支持各类信用卡)网上支付挂号费，也可以暂不交费。已交费的用户还可以打印挂号单,并在看病当天拿着预约单和挂号单直接去医院相应的科室分诊台进行分诊，分诊台的护土核查预约单和挂号单无误后盖章确认，即允许用户看病。未交费的用户需要拿着预约单到医院的挂号处交费，挂号处核查预约单，并打印出挂号单，盖章确认后交给分诊台护土进行分诊。
在看病的前天。用户可随时取消预约记录，系统不收取任何费用，已缴的费用会自动退回到用户的账号。看病当天的预约记录只能在医院挂号处现场取消，也不收取费用。但是，对于那些在网上预约成功却不去看病，也不按时取消的用户，系统会进行警告:已收取的费用不再退回.每出现一次则用户的信用等级下降1级:当用户信用等级降为0时，不再允许使用该系统。用户的初始信用等级是在审核用户注册信息时设定的。
此外，有关医生的出诊信息可以由系统管理员手动维护，也可以通过定制一些规则后由系统提前若干天(具体多少天可以由系统管理员设置)生成某日的出诊信息。
１业务建模
1.1业务用例模型
1.1.1 业务参与者及业务用例
根据项目描述识别业务参与者和业务用例，绘制业务用例图，对业务参与者可以做简要说明
1.1.2 业务用例描述
根据项目描述分析业务用例内部结构和流程，绘制业务活动图描述业务用例，每个业务用例绘制一张活动图，要求活动图划分区域。每章活动图最好有文字说明
该活动图展示了整个看病现状的全部流程，包括从患者从最开始填写病例表（患者信息）到看病问诊，直到出诊的整个流程，这其中还有其它一些分支（如退号等流程）。
由于图形本身大小的限制，该活动图的很多细节都被做了简化（如在取消预约后的相关流程）。
1.2业务对象模型
1.2.1 识别业务对象
根据项目描述分析每个业务用例中的业务工人和业务实体，对业务工人和业务实体要有说明
“支付挂号费”业务用例中：业务工人——挂号窗口工作人员；业务实体——挂号收据、诊疗卡
“审核注册信息”业务用例中：业务工人——系统管理员；业务实体——用户注册信息
“核查预约单和挂号单”业务用例中：业务工人——分诊台护士
“维护出诊信息”业务用例中：业务工人——系统管理员；业务实体——出诊信息
注： 系统管理员：对本系统进行日常维护和后台管理人员
分诊台护士：使用该系统的医院各科室分诊台的护士
挂号窗口工作人员：使用该系统的医院挂号处的工作人员
1.2.2 业务对象静态模型
分析业务工人、业务实体之间的关系（泛化、聚合、关联），建立业务对象模型。
２用例建模
2.1需求获取
2.1.1 业务改进点
分析业务用例流程，是否有可以改进的部分，如果有则描述
流程控制方面：
从看病业务现状的活动图中可以看到，从填写病例表、告诉患者该看哪科、告知患者所选专科门诊有哪些职级医生坐诊、选择挂哪一个职级医生的号、叫挂号费，再到登记挂号信息，这6个活动最终为患者建立了一个挂号收据和诊疗卡。后续的活动均基于该挂号收据和诊疗卡进行。这6个活动所构成的业务即可成为一项重要的软件需求——“预约挂号”，该项需求即可构成用例模型中一个单独的用例。
复杂业务逻辑反面：
在看病业务现状活动图中，挂号窗口工作人员要查询患者所选专科门诊有哪些职级医生，若该科职级医生恰好出诊人数已上限，则患者白跑一趟；若挂号成功，挂号窗口工作人员还要登记挂号信息。而这些都由系统来实现则相对简单，患者只需提前上网查询预约，预约信息就会自动存储在系统中。因此，该活动即可作为系统需求而存在，它将在用例“预约挂号”的流程中体现。
使用业务对象方面：
在患者挂号用例中，对于挂号数据需要频繁操作，例如生成预约单、退号等，这些操作由挂号处窗口工作人员现场完成的话会很麻烦；而通过计算机系统就可以很方便地实现这些针对挂号的操作。（注：看病当天的预约记录只能在医院挂号处现场取消）
自动化业务方面：
在维护医生出诊信息的用例中，全部由系统管理员手动维护的话工作量会很大，难以保证按时完成。所以可以通过定制一些规则后由系统提前若干天(具体多少天可以由系统管理员设置)生成某日的出诊信息。
对于那些在网上预约成功却不去看病，也不按时取消的用户，系统可以提供一些警告:已收取的费用不再退回。每出现一次则用户的信用等级下降1级:当用户信用等级降为0时，不再允许使用该系统。用户的初始信用等级是在审核用户注册信息时设定的。
2.1.2 系统需求
从项目描述中提取项目远景，列条说明
该挂号系统1期目标是实现计算机网上预约业务，后续计划会逐步实现手机上网预约、短信预约、自助预约机预约、自助电话预约等其他形式的预约业务。
通过第三方的支付系统(1期只支持淘宝的支付宝，后续支持各类信用卡)网上支付挂号费。
2.2系统用例模型
根据系统需求识别系统参与者、系统用例，建立系统用例模型，进一步识别用例之间的关系（包含、扩展、泛化），重构用例模型
2.3 系统用例描述
参考教材用例文档模板，为每个系统用例编写规格说明
表2 “预约挂号”用例文档
| 用例名 | 预约挂号 |
| 简要描述 | 注册用户可通过该用例完成预约挂号业务 |
| 参与者 | 注册用户 |
| 涉众 | 注册用户、医院 |
| 扩展点 | 打印预约单、打印挂号费、支付挂号费 |
| 前置条件 | 用户成功登录到本系统 |
| 后置条件 | 用户的预约信息被记录到系统中 |
| 基本事件流 1. 该用例起始于注册用户需要通过该系统进行预约挂号（A-1）； 2. 用户设定查询条件（D-1），查询到需要预约的医院、科室以及出诊信息； 3. 系统显示可预约的出诊信息（A-2，D-2）； 4. 用户选择一个可用的出诊信息，进行预约； 5. 系统显示有关本次预约的详细信息（D-3）； 6. 用户提交本次预约记录； 7. 系统保存本次预约记录，并提示用户预约成功（A-3）。 针对预约成功的记录，系统提供三个扩展点：打印预约单、打印挂号费、支付挂号费 | |
| 备选事件流 A-* 用户在提交该预约前，随时都可能中止本次预约 1. 系统显示中止确认的消息； 2. 用户可以结束该用例，也可以选择继续。 A-1 当用户已经有成功预约且还没看病的预约记录时 1. 系统显示用户已有的预约记录； 针对每个预约记录，系统提供三个扩展点：打印预约单、打印挂号费、支付挂号费 A-2 无法查询到所要的出诊信息 1. 系统显示没有可用的出诊信息； 2. 注册用户可以重新输入查询条件进行查询，也可以结束该用例。 A-3 保存信息失败 1. 系统显示保存失败，并提示用户需要再次提交； 2. 注册用户可以重新提交，也可以结束用例。 | |
| 补充约束-数据需求(有关数据需求尚需进一步细化) D-1目前初步应该包括：医院名称、类别、科室名称、预约时间、医生姓名、医生职称等。 D-2 出诊信息应包括：医院名称、类别、课程名称、出诊时间、医生姓名、医生职称、医生特长等内容。 D-3 预约信息应包括：出诊时间、医院、科室、医生姓名、医生职称、挂号费用等 补充约束-业务规则 B-1每个医生每次出诊所能看病的人数有一定的限制，当某个医生的预约人数满员后即不可预约 B-2一个用户每个时间段最多只能预约5位医生 | |
| 待解决问题 （暂无） | |
| 相关图 （暂无） | |
表3 “支付挂号费”用例文档
| 用例名 | 支付挂号费 |
| 简要描述 | 注册用户通过该用例支付已经预约的挂号费用 |
| 参与者 | 注册用户，支付系统 |
| 涉众 | 注册用户、医院 |
| 主用例 | 预约挂号（对应“支付挂号费”扩展点） |
| 前置条件 | 用户有已经预约成功且未支付挂号费的预约记录 |
| 后置条件 | 该预约记录的费用支付信息被成功保存到系统中 |
| 基本事件流 1. 该用例起始于注册用户通过预约挂号用例整备支付已经预约的挂号费用； 2. 用户选择某个可用的预约记录（D-1）； 3. 系统显示本次预约记录需要支付的挂号费用详细信息； 4. 用户选择支付方式，并确认进行支付； 5. 系统连接外部支付系统完成费用支付（A-1）； 6. 系统显示成功支付的信息，并修改该预约记录的状态（A-2）。 | |
| 备选事件流 A-* 用户在确认支付前，随时都可能中止本次支付 1. 系统显示中止确认的消息； 2. 用户可以结束该用例，也可以选择继续。 A-1 无法连接到外部支付系统 1. 系统显示无法连接到外部支付系统； 2. 用户可以选择重试，修改支付方式重新支付，也可以结束该用例。 A-2 外部支付系统不能完成支付 1. 系统显示支付失败信息； 2. 用户可以选择重试，修改支付方式重新支付，也可以结束该用例。 | |
| 补充约束-数据需求(有关数据需求尚需进一步细化) D-1参见预约挂号用例的D-3项数据需求。 | |
| 待解决问题 有关如何与外部支付系统连接进行支付的问题还有待进一步明确 | |
表4 “实名注册”用例文档
| 用例名 | 实名注册 |
| 简要描述 | 未注册用户通过该用例完成在系统的注册业务 |
| 参与者 | 未注册用户 |
| 涉众 | 未注册用户、医院 |
| 相关用例 | 无 |
| 前置条件 | 无 |
| 后置条件 | 如果注册成功，则用户可以进行预约挂号活动 |
| 基本事件流 1. 该用例起始于未注册用户想要进行预约挂号； 2. 系统显示本次实名注册所需信息； 3. 系统显示实名注册成功，用户可以进行下一步操作。 | |
| 备选事件流 A-* 用户在确认保存信息前，随时都可以终止该用例 1. 系统显示中止确认的消息； 2. 用户可以结束该用例，也可以选择继续。 A-1 系统保存失败 1. 系统显示保存失败信息，并提醒用户重新提交 2. 用户可以选择重新实名注册，也可以结束该用例。 | |
| 补充约束-数据需求(有关数据需求尚需进一步细化) D-1目前初步应该包括：显示需要用户填写的个人信息，如姓名、年龄、性别、职业、住址、电话号、身份号 | |
| 待解决问题 （暂无） | |
| 相关图 （暂无） | |
表5 “查询医院信息”用例文档
| 用例名 | 查询医院信息 |
| 简要描述 | 所有可以通过该用例查询医院、相关科室、各科室的医生等各类信息 |
| 参与者 | 未注册用户，注册用户 |
| 涉众 | 未注册用户、注册用户、医院 |
| 相关用例 | （无） |
| 前置条件 | （无） |
| 后置条件 | （无） |
| 基本事件流 1.该用例起始于注册用户想要查询医院信息； 2.系统显示医院各方面医疗资质及各科室和从医人员信息； 3.用户退出查询医院信息。 | |
| 备选事件流 A- 用户在注册和未注册情况下都能进行医院信息的查询工 1. 未注册用户查询医院信息，以决定是否在该医院进行实名注册； 2. 注册用户查询医院信息，以进行预约挂号。 | |
| 补充约束-数据需求(有关数据需求尚需进一步细化) 显示医院、相关科室、各科室的医生等各类信息。 | |
| 待解决问题 （暂无） | |
| 相关图 （暂无） | |
表6 “登录”用例文档
| 用例名 | 登录 |
| 简要描述 | 注册用户通过该用例登录到系统 |
| 参与者 | 注册用户、挂号处、系统管理员、分诊台护士 |
| 涉众 | 注册用户、挂号处、系统管理员、分诊台护士、医院 |
| 相关用例 | 无 |
| 前置条件 | 未注册用户已经实名注册成功 |
| 后置条件 | 用户成功登录到系统中 |
| 基本事件流 该用例起始于各职位工作人员及有需求的大众都需要登录到系统中才能进行下一步操作 | |
| 备选事件流 A-* 用户在确认登录前，随时都可能中止本次用例 1. 系统显示中止确认的消息； 2. 用户可以结束该用例，也可以选择继续。 A-1 无法登录系统 1. 系统显示无法连接到内部系统； 2. 用户可以选择重试，也可以结束该用例。 | |
| 补充约束-数据需求(有关数据需求尚需进一步细化) 用户的注册名及密码 | |
| 待解决问题 （暂无） | |
| 相关图 （暂无） | |
表7 “打印预约单”用例文档
| 用例名 | 打印预约单 |
| 简要描述 | 打印出已经预约挂号的预约单 |
| 参与者 | 注册用户 |
| 涉众 | 注册用户、医院 |
| 主用例 | 预约挂号（对应“打印预约单”扩展点） |
| 前置条件 | 用户有已经预约成功且未支付挂号费的预约记录 |
| 后置条件 | 该预约记录的信息被成功保存到系统中 |
| 基本事件流 1. 该用例起始于注册用户通过预约挂号用例完成预约； 2. 用户选择某个可预约科室的医生； 3. 系统显示本次可预约医生的详细信息； 4. 用户选择科室及医生并进行确认； 5. 系统导出预约单； | |
| 备选事件流 A-* 用户在确认预约前，随时都可能中止本次预约 1. 系统显示中止确认的消息； 2. 用户可以结束该用例，也可以选择继续。 A-1 无法连接到预约系统 1. 系统显示无法连接到预约系统； 2. 用户可以选择重试，也可以结束该用例。 A-2 外部支付系统不能完成预约 1. 系统显示预约失败信息； | |
| 补充约束-数据需求(有关数据需求尚需进一步细化) 预约信息应包括：出诊时间、医院、科室、医生姓名、医生职称、挂号费用等 补充约束-业务规则 一个用户每个时间段最多只能预约5位医生 | |
| 待解决问题 有关如何协调预约患者人数和可预约医生人数问题还有待进一步明确 | |
| 相关图 （暂无） | |
表8 “打印挂号单”用例文档
| 用例名 | 打印挂号单 |
| 简要描述 | 打印出已经预约挂号并支付费用的挂号单 |
| 参与者 | 注册用户 |
| 涉众 | 注册用户、支付系统、医院 |
| 主用例 | 预约挂号（对应“打印挂号单”扩展点） |
| 前置条件 | 用户有已经预约成功且已经支付挂号费的预约记录 |
| 后置条件 | 该预约记录的费用支付信息被成功保存到系统中 |
| 基本事件流 1. 该用例起始于注册用户通过预约挂号用例完成挂号； 2. 用户打印已经挂号（完成预约并支付相关费用）的记录； 3. 系统显示本次挂号成功的相关科室和医生信息； 4. 用户选择导出本次挂号单。 | |
| 备选事件流 （无） | |
| 补充约束-数据需求(有关数据需求尚需进一步细化) （无） | |
| 待解决问题 患者打印挂号单时发现信息错误如何改正的问题。 | |
| 相关图 （暂无） | |
表9 “取消预约”用例文档
| 用例名 | 取消预约 |
| 简要描述 | 取消已经完成的预约业务，并完成相应的费用处理 |
| 参与者 | 注册用户、挂号处、支付系统 |
| 涉众 | 注册用户、支付系统、系统管理员、时间、医院 |
| 相关用例 | （无） |
| 前置条件 | 用户有已经预约成功的记录 |
| 后置条件 | 该预约记录的医生信息被释放回系统中 |
| 基本事件流 1. 该用例起始于已成功预约用户通过该用例取消预约； 2. 用户选择某个可用的预约记录； 3. 系统显示本次取消预约记录需要返还或扣除的费用信息； 4. 用户选择确认取消预约 5. 系统连接外部支付系统完成费用返还或部分返还； 6. 系统显示成功取消预约，并修改该预约记录的状态。 | |
| 备选事件流 A-* 用户在确认取消预约前，随时都可能中止本次操作 1. 系统显示中止确认的消息； 2. 用户可以结束该用例，也可以选择继续。 A-1 无法连接到外部支付系统 1. 系统显示无法连接到外部支付系统； 2. 用户可以选择重试，也可以结束该用例。 A-2 外部支付系统不能完成费用返还 1. 系统显示支付或返还失败信息； 2. 用户可以选择重试，也可以选择向医院反映此问题。 | |
| 补充约束-数据需求(有关数据需求尚需进一步细化) （暂无） | |
| 待解决问题 有关如何与外部支付系统连接进行费用返还的问题还有待进一步明确 | |
表10 “审核注册信息”用例文档
| 用例名 | 审核注册信息 |
| 简要描述 | 审核用户提交的注册信息是否合法 |
| 参与者 | 系统管理员 |
| 涉众 | 系统管理员、注册用户、医院 |
| 相关用例 | 无 |
| 前置条件 | 用户已提实名交注册信息 |
| 后置条件 | 该注册信息被保存到系统中 |
| 基本事件流 1. 该用例起始于未注册用户提交注册信息； 2. 系统管理员审核用户提交的信息是否合法； 3. 系统显示成功注册的信息，并修改该注册的状态。 | |
| 备选事件流 A-* 用户实名注册信息不合法，返回数据要求客户重新填写先关信息 | |
| 补充约束-数据需求(有关数据需求尚需进一步细化) 目前初步应该包括姓名、年龄、性别、职业、住址、电话号、身份号 | |
| 待解决问题 有关获得用户的真实信息 | |
| 相关图 （暂无） | |
表11 “维护出诊信息”用例文档
| 用例名 | 维护出诊信息 |
| 简要描述 | 设定医生的出诊情况，也可通过定义相应的业务规则由系统自动生成出诊信息 |
| 参与者 | 系统管理员 |
| 涉众 | 系统管理员、注册用户、时间、医院 |
| 相关用例 | 无 |
| 前置条件 | 注册用户与医生间的预约记录及取消预约记录 |
| 后置条件 | 使各科室及医生的工作时间稳定 |
| 基本事件流 1. 该用例起始于注册用户与医生间的预约记录及取消预约记录的维护； 2. 系统管理员可选择某个可用的预约记录 3. 系统显示可预约医生、已预约医生及相关信息； 4. 系统管理员可修改相关出诊信息 | |
| 备选事件流 （暂无） | |
| 补充约束-数据需求(有关数据需求尚需进一步细化) （暂无） | |
| 待解决问题 系统管理员的修改权限问题 | |
| 相关图 （暂无） | |
表12 “生成出诊信息”用例文档
| 用例名 | 生成出诊信息 |
| 简要描述 | 系统根据管理员设定的规则自动生成出诊信息 |
| 参与者 | 时间 |
| 涉众 | 时间、系统管理员、注册用户、医院 |
| 相关用例 | 无 |
| 前置条件 | 系统管理员设定相关规则 |
| 后置条件 | 出诊信息被成功保存到系统中 |
| 基本事件流 1. 系统自动生成出诊信息； 2. 系统显示出诊信息，并记录出诊状态。 | |
| 备选事件流 1. 无法显示出诊信息 2. 系统显示无法连接到系统； | |
| 补充约束-数据需求(有关数据需求尚需进一步细化) 出诊信息应包括：医院名称、类别、课程名称、出诊时间、医生姓名、医生职称、医生特长等内容。 | |
| 待解决问题 （暂无） | |
表13 “处理预期未取消预约”用例文档
| 用例名 | 处理预期未取消预约 |
| 简要描述 | 处理那些预期未取消的也未看病的预约记录 |
| 参与者 | 时间 |
| 涉众 | 时间、注册用户、系统管理员、医院 |
| 相关用例 | 无 |
| 前置条件 | 存在预期未取消的也未看病的预约记录 |
| 后置条件 | 记录该预约记录 |
| 基本事件流 1. 该用例起始于存在预期未取消的也未看病的预约记录； 2. 系统显示该预约具体情况，包括患者、医生、及支付情况 3. 处理该记录并记录。 | |
| 备选事件流 （无） | |
| 补充约束-数据需求(有关数据需求尚需进一步细化) （暂无） | |
| 待解决问题 有关如何与外部支付系统连接进行支付的问题还有待进一步明确 | |
表14 “核查预约单和挂号单”用例文档
| 用例名 | 核查预约单和挂号单 |
| 简要描述 | 核查用户的预约单和挂号单是否合法 |
| 参与者 | 分诊台护士 |
| 涉众 | 分诊台护士、挂号处、注册用户、医院 |
| 相关用例 | 核查预约单（对应“核查预约单”扩展点） |
| 前置条件 | 系统显示预约单，核查预约单完成 |
| 后置条件 | 打印挂号单 |
| 基本事件流
| |
| 备选事件流 （无） | |
| 补充约束-数据需求(有关数据需求尚需进一步细化) （暂无） | |
| 待解决问题 （暂无） | |
| 相关图 （暂无） | |
2.4其他需求
性能、可靠性、容错性、安全性等，如果有则描述
系统应具备自动备份功能，以防系统管理员误删或误修改问题。
3用例分析
3.1静态分析模型
依据B-C-E三层备选架构针对每个系统用例识别边界类、控制类和实体类，建立系统静态分析模型，绘制系统分析类图。
3.2动态分析模型
依据系统分析类图，针对每个系统用例分析对象之间的交互，用顺序图描述每个用例实现。
3.3定义分析类
依据动态分析结果，定义每个分析类的职责和属性以及类之间的关系，进一步完善静态分析模型，绘制完善后的分析类图。
图9 完善后的分析类图
