系统分析与设计第四次作业
1. 用例建模
a. 阅读 Asg_RH 文档，绘制用例图。 按 Task1 要求，请使用工具 UMLet，截图格式务必是 png 并控制尺寸
b. 选择你熟悉的定旅馆在线服务系统（或移动 APP），如绘制用例图。并满足以下要求：
- 对比 Asg_RH 用例图，请用色彩标注出创新用例或子用例
- 尽可能识别外部系统，并用色彩标注新的外部系统和服务
以美团预约酒店为例：
c. 对比两个时代、不同地区产品的用例图，总结在项目早期，发现创新的思路与方法
| 项目 | 特点 |
|---|---|
| 早期 | 仅具备基本的核心业务，满足用户预定酒店的基本需求 |
| 美团订酒店 | 除了具备早期酒店预订系统的业务外，提供更多的业务功能，例如使用地图导航系统的API接口，提供用户导航及位置查询的功能；此外，也提供酒店评分、网友评价等功能，满足用户进一步的需求 |
在项目早期，对比类型相近的系统，提供同类型系统的核心业务功能。此外，在用户需求调研基础上，进一步完善功能，针对不同用户能够提供定制化服务。
d. 请使用 SCRUM 方法，在（任务b）用例图基础上，编制某定旅馆开发的需求 （backlog）
产品BACKLOG
产品backlog是Scrum的核心，也是一切的起源。从根本上说，它就是一个需求、或故事、或特性等组成的列表，按照重要性的级别进行了排序。它里面包含的是客户想要的东西，并用客户的术语加以描述。我们叫它故事（story），有时候也叫做backlog条目。
我们的故事包括这样一些字段：
ID —— 统一标识符。
Name —— 简短的、描述性的故事名。比如“查看你自己的交易明细”。它必须要含义明确，这样开发人员和产品负责人才能大致明白我们说的是什么东西，跟其他故事区分开。它一般由2到10个字组成。
Importance —— 产品负责人评出一个数值，指示这个故事有多重要。例如10或150。分数越高越重要。
Initial estimate —— 团队的初步估算，表示与其他故事相比，完成该故事所需的工作量。最小的单位是故事点（story point），一般大致相当于一个“理想的人天（man-day）”。
How to demo —— 它大略描述了这个故事应该如何在sprint 演示上进行示范，本质就是一个简单的测试规范。“先这样做，然后那样做，就应该得到……的结果”。
Notes —— 相关信息、解释说明和对其它资料的引用等等。一般都非常简短。
| ID | Name | Imp | Est | How to demo | Notes |
|---|---|---|---|---|---|
| 1 | 酒店搜索 | 100 | 14 | 根据用户选择的城市及其他关键词（地名、酒店名等），显示酒店搜索结果。显示的信息包括详细位置、酒店价格、网友评分等。 | 根据用户的当前位置以及酒店的评价，对酒店显示的先后顺序进行智能排序 |
| 2 | 酒店预订 | 100 | 10 | 选择城市，选择酒店，选择房型，选择日期，进行预订。预订时，需要用户填写基本信息，包括姓名、手机号等。订单填写完成后，支付订单。支付成功后，返回入住的个人信息以及相关事项。 | 支付失败时，仍旧保留订单到待支付列表中 |
| 3 | 订单查询 | 50 | 8 | 用户可以在个人中心查询到历史订单 | 订单自动分类为：已完成订单、已支付但待入住订单、待支付订单 |
| 4 | 用户评价 | 20 | 8 | 用户可以针对酒店的环境、服务等方面进行评分，也支持文字及图片评价 | 可以参考淘宝订单星级评价的评价方式 |
| 5 | 地图导航 | 30 | 6 | 利用地图系统的API，为用户提供位置查询及导航功能 | 结合其他系统实现 |
2. 业务建模
a. 在（任务b）基础上，用活动图建模找酒店用例。简述利用流程图发现子用例的方法。
b. 选择你身边的银行 ATM，用活动图描绘取款业务流程
c. 查找淘宝退货业务官方文档，使用多泳道图，表达客户、淘宝网、淘宝商家服务系统、商家等用户和系统协同完成退货业务的过程。分析客户要完成退货业务，在淘宝网上需要实现哪些系统用例
3. 用例文本编写
在大作业基础上，分析三种用例文本的优点和缺点
这里先总结一下上述的三种UML图，（其实是发现写错了写成了三种图的优缺点…)
| 用例文本 | 优点 | 缺点 |
|---|---|---|
| 用例图 | 站在用户的角度，描述用户的需求。用例图包含了用例和参与者，用例之间用关联来连接以求反映系统的整个结构和功能，能够精准得表达用户功能需求。同时，用例图是UML建模中比较常用的一个图，规范且易于理解。 | 用例图不能表达非功能需求。此外，用例图不涉及设计实现细节，只是一个功能划分，许多细节无从谈起，需要其他工具的辅助说明。 |
| 活动图 | 阐明了业务用例实现的工作流程。活动图强调的是从活动到活动的控制流。 | 活动图关注完整的业务流程，而不是业务的具体实现 |
| 泳道图 | 在活动图中，每个活动只能明确的属于一个泳道。而在泳道图中，每个泳道代表特定含义的状态职责部分。因此，泳道图区分了负责活动的对象，明确地表示了哪些活动是由哪些对象进行的。 | 依旧缺乏细节实现，用于软件开发前期的需求理解。 |
用例能够以不同形式化程度或格式进行编写：
- 摘要 —— 简洁的一段式概要，通常用于主成功场景。前例中的处理销售就是摘要形式的用例。在早期需求分析过程中，为快速了解主题和范围可以使用。
- 非正式 —— 非正式的段落格式。用几个段落覆盖不同场景。同样的，在早期需求分析过程中，为快速了解主题和范围可以使用。
- 详述 —— 详细编写所有步骤及各种变化，同时具有补充部分，如前置条件和成功保证。确定并以摘要形式编写了大量用例后，在第一次需求讨论会中，详细地编写其中少量的具有重要架构意义和高价值的用例。